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Preface 



This volume contains selected papers from LOPSTR 2003, the 13th Interna- 
tional Symposium on Logic-Based Program Synthesis and Transformation. The 
LOPSTR series is devoted to research in logic-based program development. Par- 
ticular topics of interest are specification, synthesis, verification, transformation, 
specialization, analysis, optimization, composition, reuse, component-based soft- 
ware development, agent-based software development, software architectures, 
design patterns and frameworks, program refinement and logics for refinement, 
proofs as programs, and applications and tools. 

LOPSTR 2003 took place at the University of Uppsala from August 25 to 
August 27 as part of PLI 2003 (Principles, Logics, and Implementations of High- 
Level Programming Languages). PLI was an ACM-organized confederation of 
conferences and workshops with ICFP 2003 (ACM-SIGPLAN International Con- 
ference on Functional Programming) and PPDP 2003 (ACM-SIGPLAN Interna- 
tional Conference on Principles and Practice of Declarative Programming) as the 
main events. The LOPSTR community profited from the shared lectures of the 
invited speakers, and the active scientific discussions enabled by the co-location. 

LOPSTR 2003 was the thirteenth in a series of events. Past events were held 
in Manchester, UK (1991, 1992, 1998), Louvain-la-Neuve, Belgium (1993), Pisa, 
Italy (1994), Arnhem, The Netherlands (1995), Stockholm, Sweden (1996), Leu- 
ven, Belgium (1997), Venice, Italy (1999), London, UK (2000), Paphos, Cyprus 
(2001), and Madrid, Spain (2002). 

I wish to thank the PLI Organizing Committee and especially Kostis Sago- 
nas for welcoming LOPSTR as part of PLI 2003 and taking care of the many 
organizational matters. Special thanks go towards Roland Bol for taking care of 
LOPSTR specific matters in Uppsala, towards Wim Vanhoof for assistance with 
the Program Chair work, and towards Qiang Fu for the help in preparing this 
volume. The sponsorship of the Association for Logic Programming (ALP) is 
gratefully acknowledged, and the LNCS team of Springer- Verlag is thanked for 
publishing this volume with the selected and revised papers. Last but not least, 
authors, PC members and additional reviewers are thanked for all the work that 
went into preparing this selection of revised papers. 

Out of 32 submissions, the program committee selected 18 works for presen- 
tation; 16 were revised and submitted for this volume. The program committee 
selected 12 of them for inclusion in this volume. In addition, a paper based on 
the invited talk of Michael Leuschel is included as well as some abstracts based 
on the other papers presented at LOPSTR. 

The preproceedings were printed in Uppsala and are also available at 
http://www.cs.kuleuven.ac.be/ dtai/lopstr03/, a page with all information about 
LOPSTR 2003. 
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Inductive Theorem Proving 
by Program Specialisation: 
Generating Proofs for Isabelle Using Ecce 



Helko Lehmann and Michael Leuschel 

Department of Electronics and Computer Science 
University of Southampton 
Highfield, Southampton, S017 IBJ, UK 
{hel99r ,mal}@ecs . soton. ac .uk 



Abstract. In this paper we discuss the similarities between program 
specialisation and inductive theorem proving, and then show how pro- 
gram specialisation can be used to perform inductive theorem proving. 
We then study this relationship in more detail for a particular class of 
problems (verifying infinite state Petri nets) in order to establish a clear 
link between program specialisation and inductive theorem proving. In 
particular, we use the program specialiser ECCE to generate specifica- 
tions, hypotheses and proof scripts in the theory format of the proof 
assistant Isabelle. Then, in many cases, Isabelle can automatically 
execute these proof scripts and thereby verify the soundness of ecce’s 
verification process and of the correspondence between program special- 
isation and inductive theorem proving. 



1 Introduction 

Program specialisation aims at improving the overall performance of programs 
by performing source to source transformations. A common approach, known 
as partial evaluation [8], is to exploit partial knowledge about the input by 
precomputing parts of the program. In the context of logic programming, par- 
tial evaluation is sometimes called partial deduction and is achieved through a 
well-automated application of parts of the Burstall-Darlington unfold/fold trans- 
formation framework. 

The relation between program specialisation and theorem proving has already 
been raised several times in the literature [23,7,24,21]. In this paper we will 
examine in closer detail the relationship between partial deduction and inductive 
theorem proving. 

Partial Deduction. At the heart of any technique for partial deduction is a 
program analysis phase: Given a program P and an (atomic) goal •<— A, one 
aims to analyse the computation-flow of P for all instances ^ A6 of ^ A. Based 
on the results of this analysis, new program clauses are synthesised. 
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In partial deduction, such an analysis is based on the construction of finite 
and usually incomplete^, SLD(NF)-trees. More specifically, following the foun- 
dations for partial deduction developed in [17] (see also [12] for an up-to-date 
overview), one constructs 

— a finite set of atoms S = {Ai, . . . , An}, and 

— a finite (possibly incomplete) SLD(NF)-tree n for each (P U Ai}), 
such that: 

1) the atom A in the initial goal ^ A is an instance of some Ai in S, and 

2) for each goal ^ Bi, . . . ,Bk labelling a leaf of some SLD(NF)-tree ti, each 
Bi is an instance of some Aj in S. 

The construction of the set S is referred to as the global control, while the 
construction of the trees Ti are called the local control. The conditions 1) and 
2) are referred to as closedness and ensure that together the SLD(NF)-trees 
Ti , . . . , r„ form a complete description of all possible computations that can 
occur for all concrete instances ^ Ad of the goal of interest. Finally, a code 
generation phase produces a resultant clause for each non-failing branch of each 
tree, which synthesises the computation in that branch. This phase also typically 
generates a fresh predicate name for every element of the set S and rename the 
clauses in an appropriate manner. 

The approach has been generalised to specialising a set of conjunctions rather 
than just atoms in [4]. The basic principle remains roughly as outlined above; 
the only difference being that we have a set S of conjunctions rather than atoms 
and that the closedness condition becomes slightly more involved to allow the 
leaf goals ^ Bi, ... ,Bk to he split up into sub-conjunctions. This technique has 
been implemented within the program specialiser ecce [15,4] . An overview of 
control techniques that are used in partial deduction and conjunctive partial 
deduction in general and by ECCE in particular, such as determinacy, homeo- 
morphic embedding, or characteristic trees, can be found in [12]. 



A Small Example. Let us illustrate conjunctive partial deduction on the fol- 
lowing simple program. 

even(O) . 

even(s(X)) odd(X) . 

odd(s(X)) even(X) . 

Suppose we only wish to use this program for queries of the form •<— C 
with C = even{X) A odd{X) Conjunctive partial deduction can then specialise 
this program by constructing the incomplete SLD-tree for •<— C depicted in 

^ As usual in partial deduction, we assume that the notion of an SLD-tree is generalised 
[17] to allow it to be incomplete: at any point we may decide not to select any atom 
and terminate a derivation. 
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eyen(X),odd(X) 



x=o 

odd(0) 



X=s(Y) 

\ 



odd(Y).odd ( s ( Y )) 



T ▼ 

fail odd(Y),even(Y) 



instance 

(after re-ordering) 



Fig. 1. Specialisation of even-odd 



Fig. 1. The set S mentioned above would simply be S' = {C}. Supposing that 
we produce the new predicate name even_odd for C, the specialised program we 
obtain, is: 

even_odd(s (X) ) even_odd(X) . 



It is immediately obvious that even-odd(X) will never succeed, and hence 
that no number is even and odd at the same time. The ecce system [15, 4] 
basically produces the above result^ and can also automatically infer the failure 
of everi-odd{X) by applying its bottom up more specific program construction 
phase [18] in the post-processing. 

Inductive Theorem Proving. Now, the above result corresponds to an induc- 
tive proof showing that no number can be both even and odd. The left branch of 
Fig. 1 corresponds to examining the base case X = 0, while the right branch cor- 
responds to the induction step whereby even{s(Y)) , odd{s{Y)) is rewritten into 
the equivalent odd{Y), even{Y) so that the induction hypothesis can be applied. 

In a sense the conjunctive partial deduction has identified a working induction 
schema and the bottom-up propagation [18] has performed the induction proper. 
This highlights a similarity between partial deduction and inductive theorem 
proving. Indeed, in the induction step of an inductive proof one tries to transform 
the induction assumption(s) for n -I- 1 using basic inference rules so as to be able 
to apply the induction hypothese(s) and complete the proof. In partial deduction, 
one tries to transform the atoms in A (or conjunctions for conjunctive partial 
deduction) by unfolding so as to be able to “fold” back all leaves. The set of 
atoms A thus plays the role of the induction hypotheses and resolution the role 
of classical theorem proving steps. In summary, 

— there is a striking similarity between the control problems of partial deduc- 
tion and inductive theorem proving. The problem of ensuring A-closedness is 
basically the same as finding induction hypotheses where the induction “goes 
through.” Many control techniques have been developed in either camp (e.g., 
[1] for inductive theorem proving) and cross-fertilisation might be possible. 

^ Using the default settings, ECCE produces a slightly bigger specialised program be- 
cause it does not re-order atoms by default. But the overall result is the same. 
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— if basic resolution steps correspond to logical inference rules one may be able 
to perform inductive theorem proving directly by partial deduction. 

The only difference is that unfolding steps are not guaranteed to decrease 
the induction parameter, so program specialisation is only guaranteed to 
perform valid inductive theorem proving if the predicates to be specialised 
are inductively defined. 

A More Complicated Example. Let us now have a look at a slightly more 
involved example. The following is a simple theory expressed in the proof as- 
sistant Isabelle [19]. (We will provide more details about Isabelle later in 
the paper.) The theory defines a datatype for binary trees and then defines the 
function mirror which simply produces the mirror image of tree (i.e., reversing 
left and right children for all nodes). We then define a lemma stating that ap- 
plying mirror twice produces the same result and then instruct Isabelle to use 
induction on the tree in order to show this lemma, 
theory ToyTree = PreList: 

datatype ’a tree = Tip ("[]") 

I Node "’a tree" ’a "’a tree" 
consts mirror :: "’a tree => ’a tree" 
primrec 

"mirror([]) = [] " 

"mirror ( (Node Is x rs)) = Node (mirror(rs)) x (mirror (Is) ) " 
lemma mirror_mirror [simp]: "mirror (mirror(xs) ) = xs" 
apply (induct_tac xs) 

Loading this theory int Isabelle results in the following output: 

proof (prove) : step 1 
fixed variables: xs 

goal (lemma (mirror_mirror) , 2 subgoals) : 

1 . mirror (mirror [] ) = [] 

2 . ! ! treel a tree2 . 

[| mirror (mirror treel) = treel; mirror (mirror tree2) = tree2 |] 
==> mirror (mirror (Node treel a tree2)) = Node treel a tree2 



It is now possible to use Isabelle to prove this lemma, by interactively 
performing the required rewriting steps and twice applying the induction hy- 
pothesis^. 

Let us now try to achieve the same result using program specialisation. First, 
we have to encode the mirror function and the lemma as a logic program: 

mirror(tip,tip) . 

mirror (tree(L,N,R) , tree (RR,N,RL) ) :- mirror (L,RL) , mirror (R,RR) . 
lemma(X,R) :- mirror (X,Z) .mirror (Z,R) . 



® E.g., first calling the simplifier apply(simp) and then the automatic prover 
apply (auto) will perform the required proof steps. 
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lemma 1(A.B) == 

rr(A,B) 



mirror_conj 2(A,C) = 




» mirror(A.B), 
mirror(B.C) 



X 



mirror{A,B). 

nTirrorgijCj^ 



mirror(A.B). 



(^niTOTtigj^ mirror(C.D). 



_mirror|lreegjEj^^ 






mirror(A,B), 

mirror(C.D), 

mirror(D.E), 

mirrorjBj2^ 



Fig. 2. ECCE specialisation tree for mirror 



Now, one would like to be able to infer that for all valid trees the the second 
argument of lemma must be identical to the first argument. Surprisingly this 
is exactly what we obtain when we specialise the above program for the call 
lemma (X,R) using the ECCE program specialiser (with the most specific version 
[18] postprocessing enabled): 

/* Transformation time: 130 ms */ 

/* Specialised Predicates: 
lemma 1(A,B) :- lemma(A,B) . 

mirror_conj 2(A,B) :- mirror(A,Cl) , mirror(Cl,B) . */ 

lemma (A, A) :- mirror_conj 2(A,A) . 

lemma 1(A,A) :- mirror_conj 2 (A, A). 

mirror_conj 2 (tip, tip) . 

mirror_conj 2 (tree ( A , B , C) , tree ( A , B , C) ) : - 

mirror_con j 2 ( A , A) , mirror_conj 2 (C , C) . 

Again, ECCE has managed to rewrite the lemma in such a way that the 
induction hypothesis could be applied (in this case it was applied twice as can be 
seen from the two instances of mirror _conj __2 in the last clause of the specialised 
program). The specialisation tree produced by ECCE can be seen in Fig. 2. The 
dashed arrows indicate a descendance at the global control level (see, e.g., [12]), 
whereas the solid arrows indicate unfolding steps. By carefully inspecting the 
proof trace of Isabelle and the specialisation tree of ECCE it turns out that 
there is a one-to-one correspondence between the steps performed by Isabelle 
and by ECCE. 

An obvious question is now whether there is a systematic way to exploit this 
correspondence? In the next sections we show how ECCE can be used to perform 
inductive theorem proving as applied to verification tasks and how the special- 
isation trees produced by ECCE can be automatically translated into induction 
schemas for the proof assistant Isabelle [19]. 
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2 Infinite Model Checking by Program Specialisation 

In recent work it has been shown that logic programming based methods in 
general, and partial deduction in particular, can be applied to model checking 
[2] of infinite state systems. As this problem can also be tackled by inductive 
theorem proving [19] we choose this as the basis of a more formal comparison. 
Indeed, one of the key issues of model checking of infinite systems is abstrac- 
tion [3]. Abstraction allows to approximate an infinite system by a finite one, 
and if proper care is taken the results obtained for the finite abstraction will be 
valid for the infinite system. This is related to finding proper induction schemas 
for inductive theorem proving, which in turn is related to the control problem 
of partial deduction. 

In earlier work we have tried to solve the abstraction problem by applying 
existing techniques for the automatic control of (logic) program specialisation, 
[12] and modelling the system to be verified as a logic program by means of an 
interpreter [16]. Thereby, the interpreter describes how the states of the system 
change by executing transitions. By applying partial deduction to the interpreter 
we expect a finite abstraction of the possibly infinite state space of the system 
to be generated. This abstraction may then be used to verify system properties 
of interest. This approach proved to be quite powerful as it was possible to ob- 
tain decision procedures for the coverability problem, if “typical” specialisation 
algorithms, as for example implemented in the ecce system [15, 10], are applied 
to logic programs that encode Petri nets [14]. 

Technically, the dynamic system specified in the input for the partial deduc- 
tion algorithm can also be viewed as an inductive system describing the set of 
finite behaviours, i.e. the set of finite paths. Thereby, the set of initial states 
form the inductive base and each transition represents an inductive step. For 
the output of the partial deduction algorithm to be a sound abstraction each of 
the states reachable by a path must be contained in a state representation of 
the output. It is desirable to verify this property if we cannot ensure that the 
partial deduction algorithm is correctly implemented. The goal of this work is 
to show that such proofs can be generated and executed automatically. To this 
end we employ the partial deduction system ECCE for the automatic generation 
of the theory and the proof scripts. The proof assistant Isabelle [20] is used to 
execute the proof scripts. 

If we can use Isabelle to verify the soundness of the output of the partial 
deduction method we may also ask whether it is possible to generate the hy- 
potheses automatically and thereby use Isabelle directly as a model checker of 
infinite systems. To this end, similar to the partial deduction system, Isabelle 
needs to perform some kind of abstraction while searching for a proof of some 
dynamic property such as safety. 

In this paper we focus on the specification and verification of Petri nets. 
This is due to their simple representation as a logic program as well as in a 
Isabelle theory. The following section describes how we can specify Petri nets 
in Isabelle. Then we discuss how such specifications are generated using ECCE 
and how ECCE output can be translated into Isabelle. In Section 5 we demon- 
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strate how proof scripts can be used in Isabelle for automatic theorem proving. 
In Section 6 we demonstrate the complete verification process using an exam- 
ple specification. The last section gives a conclusion and proposes some further 
work. All relevant source code of the ecce system can be found in the technical 
report [9]. 

3 Specification of Petri Nets in Isabelle 

The proof assistant Isabelle [19] has been developed as a generic system for 
implementing logical formalisms. Instead of developing an all new logic for our 
purposes we will use the specification and verification methods realised by the 
implementation of Higher Order Logic (HOL) in Isabelle. HOL allows to ex- 
press most mathematical concepts and, in contrast to, for example. First Order 
Logic, it allows the specification of and the reasoning about inductively defined 
sets. This latter feature is crucial for our purposes. Hence, strictly speaking, 
we will develop specifications in Isabelle/HOL. Furthermore, the current Is- 
abelle system provides the language ISAR for the specification of theories and 
the development of proof scripts. In this work we will use ISAR instead of Is- 
abelle’s implementation language ML since ISAR is much easier to use as it 
hides most implementation details of Isabelle. However, the possibilities to de- 
velop proof tactics using ISAR only are very limited. Consequently we conjecture 
that for efficient automatic theorem proving the use of ISAR allone is insufficient 
(see also Section 7). 

Isabelle allows specifications as part of theories. A theory can be thought of 
as a collection of declarations, definitions, and proofs. Isabelle/HOL is a typed 
logical language where the base types resemble those of functional programming 
languages such as ML. To specify new types Isabelle provides type construc- 
tors, function types, and type variables. We will introdce the particular concepts 
as we will use them and refer for additional information to [19]. 

Terms are formed by applying functions to arguments, e.g. if / is a function 
of type Ti T 2 and t a term of type Ti then ft is a term of type T 2 . 

Formulas are terms of base type bool. Accordingly, the usual logical opera- 
tors are defined as functions whose arguments and domain are of type bool. 

We specify the Petri net theory PN as a successor of the theory Main which 
is provided by Isabelle/HOL. Main contains a number of basic declarations, 
definitions, and lemmas concerning often required basic concepts such as lists 
and sets. Thereby, every part of the theory Main becomes automatically visible 
in PN: 

theory PN = Main: 

To simplify the specification and to increase readability of the theory we 
define the type state which corresponds to a notion in Petri net theory: A state 
or marking is a vector of natural numbers representing the number of tokens on 
the places of a Petri net. The number of dimensions of the vector corresponds 
to the number of places of the particular net. In Isabelle we use the type 
constructor x to define the type state as a product over the base type nat: 
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types 

state = "nat X nat X...X nat" 

Based on the type state we declare the functions paths, trans, and start. 
The function start represents the initial state of the Petri net. Note that since 
we allow parameters in the definition of state it actually may represent a set 
of initial states. The function trans describes how the firing of a transition can 
change the state of a Petri net. The additional parameter of type nat is used 
to refer to a particular transition of the net. The set of finite possible sequences 
of transitons starting in the initial state is represented by paths. Note that the 
declaration of trans and paths is independent of the particular considered Petri 
net. 

consts 

start :: "nat ^ ...^ nat ^ state" 
trans :: "(state X state X nat) set" 
paths :: "(state list) set" 

By assigning a unique number the transition names are defined as a of enu- 
meration type. Consequently, for each transition t we include a declaration of 
the following form: 

consts 
t : : "nat" 

The initial state start is defined by a term term of type state: 
def s 

start_def [simp] : "start list of variables = term" 

The optional [simp] controls the strategy of Isabelle’s built-in simplifier 
to apply this definition whenever possible. For our purposes term will be always 
a tuple of terms built using the unary successor function Sue, 0, and variables 
appearing in the list of variables (the number of variables in this list must cor- 
respond to the number of parameters in the declaration of start. 

The transition function is defined as a set of transitions of the Petri net. 
Thereby each transition is represented as a tuple (x,y,n), where x and y are 
tuples of terms built by Sue and variables of the corresponding list of variables. 
The term n is the name of the transition. 

def s 

trans_def : "trans = {(x,y,n). 

(3 listi of variables. (x,y,n)= transitioni 

V (3 list 2 of variables. (x,y,n)= transition 2 

V (3 listn of variables. (x,y,n)= transition„} " 
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One of the important features of Isabelle/HOL is the possibility of inductive 
definitions. We define paths inductively using the following two rules: 

inductive paths 
intros 

zero: "[(start list of variables)] € paths" 

step: "[(y,z,n) € trans; y#l G paths] z#(y#l) G paths" 

The first rule defines all initial states to be paths. The second rule allows the 
construction of new paths by extending an arbitrary path by a new state if there 
exists a transition from the state at the head of the path to the new state. 

Finally, each transition t is defined as follows, where n is a unique natural 
number: 

def s 

t_def [simp] : "t = n" 

The following example shows the the specification of a Petri net according 
to this scheme. 

Example 1. We encode the Petri net depicted below in Isabelle/HOL. The 
initial state is defined by one token on each of the places p2 and p3, and the 
parameter A representing an arbitrary number of tokens on place pi (pi, p2, p3 
correspond to the first, second, and third dimension, respectively, of the state 
vector. 



ti 




theory PN = Main: 
types 

state = "nat X nat X nat X nat X nat" 
consts 

start : : "nat state" 

trans :: "(state X state X nat) set" 

paths :: "(state list) set" 

tl : : "nat" 



10 



Helko Lehmann and Michael Leuschel 



t2 : : 


"nat 


t3 : : 


"nat 


t4 : : 


"nat 


def s 





start_def [simp]: "start = (B,(Suc 0) , (Sue 0),0,0)" 

trans_def : "trans = {(x,y,n). 

(3 E D C B A. (x,y,n) = (((Suc A) , (Sue B) , (Sue C),D,E), 

(A, (Sue B),C,(Sue D),E),tl)) 

V (3 E D C B A. (x,y,n) = (((Sue A) , (Sue B) , (Sue C),D,E), 

(A,B,(Sue C),D,(Sue E)),t2)) 

V (3 E D C B A. (x,y,n) = ((A,B,C, (Sue D) ,E) , 

((Sue A),B,(Sue C),D,E),t3)) 

V (3 E D C B A. (x,y,n) = ((A,B,C,D, (Sue E)), 

((Sue A). (Sue B) ,C,D,E) ,t4) ) }" 

tl_def [simp] : "tl = 0" 
t2_def [simp] : "t2 = 1" 
t3_def [simp] : "t3 = 2" 
t4_def [simp] : "t4 = 3" 

induetive paths 
intros 



zero: "[(start B)] S paths" 

step: "|(y,z,n) S trans; y#l £ paths] => z#(y#l) S paths" 



□ 



4 Generating Isabelle Theories Using ecce 

Since we aim to verify the partial deduction results of ECCE, we have integrated 
the generation of the Isabelle theory directly into ECCE. The generated Is- 
abelle theory consists of three parts: 

1. the specification of the Petri net, 

2. the specification of the coverability graph [5] as generated by ECCE, 

3. the lemma to be verified together with a proof script. 

In this section we deal with the first two parts while the third part is discussed 
in Section 5. 



4.1 Generating Petri Net Specifications from Logic Programs 

The Isabelle theory generator integrated in ECCE assumes that the transitions 
of a Petri net are specified by a set of clauses of a ternary predicate. The first 
parameter represents a transition name, the second represents the set of states 
where the transition can be applied, and the third how the state changes if the 
transition is executed. Technically, the second and the third parameter of each 
clause are lists of the length corresponding to the number of places. Relying 
on unification, conditions and changes can be easily expressed. For example, the 
condition that at least two tokens are on place p3 in a Petri net with five places is 
expressed by the term [X0,Xl,s(s(X2)) ,X3,X4] (thereby s can be interpreted 
as the successor function on natural numbers). Similarly, the state change can 
be expressed: the removal of one token on place p3 and generation of two tokens 
on pi is represented as [s(s(X0)) ,Xl,s(X2) ,X3,X4]. 
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The initial state is simply represented as a single clause where the last pa- 
rameter must be a list of the length corresponding to the number of places. 
Each element of the list can be constructed using 0, the unary function s, and 
variables. 

Example 2. The following logic program encodes the Petri net of Example 1. 

transCtl, [s (XO) , s (XI) , s (X2) ,X3,X4] , [X0,s(Xl) ,X2,s(X3) ,X4] ) . 
trans(t2, [s (XO) , s (XI) , s (X2) ,X3,X4] , [X0,Xl,s(X2) ,X3,s(X4)] ) . 
trans(t3, [X0,Xl,X2,s(X3) ,X4] , [s(X0) ,Xl,s(X2) ,X3,X4]) . 
trans(t4, [X0,Xl,X2,X3,s(X4)] , [s(X0) ,s(Xl) ,X2,X3,X4]) . 

start ( [B,s(0) ,s(0) ,0,0] ) . 

The implementation of the theory generator is part of the file “code-genera- 
tor. pro” and can be found in [9]. The generation is initiated by a call to the 
clause print_specialised_program_isa. For example, the Isabelle theory of 
Example 1 has been generated from the logic program of Example 2. 

4.2 Generating Specifications of the Coverability Graph 
from Logic Programs 

To use partial deduction techniques for model checking we need to specify also 
the verification task as a logic program. To this end we may implement the 
satisfiability relation of some temporal logic as a logic program, such as the 
CTL interpreter described in [16]. In this paper we restrict ourselves to safety 
properties and hence we only need definition of the EU operator of the temporal 
logic CTL, and we just need the following subset of the interpreter from [16]: 

model_ch.eck_saf ety start(_,S), sat(S,eu(true,p(unsafe))) . 

sat(E,p(P)) prop(E,P). 
sat(E,eu(F,G)) sat_eu(E,F,G) . 

sat_eu(E,_F,G) sat(E,G). 

sat_eu(E,F,G) sat(E,F), trans(_Act,E,E2) , sat_eu(E2,F,G) . 

Depending on the safety property of interest, we have to define prop/2. E.g., 
the fact prop( [X0,Xl,X2,s(X3) ,s(X4)] , unsafe) defines a state of a Petri net 
to be unsafe when there exist at least one token on each of the places p4 and p5. 

Note that simply calling model_check_saf ety in Prolog would lead to an 
infinite derivation. Due to the potentially infinite state space of a Petri net also 
methods like tabling will be insufficient to deal with this problem. 

To perform the verification we use the same approach as in [14]. Hence, before 
we apply the partial deduction system ecce we will first perform a preliminary 
compilation of the particular Petri net and task. Thereby we will get rid of some 
of the interpretation overhead and achieve a more straightforward equivalence 
between markings of the Petri net and atoms encountered during the partial 
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deduction phase. We will use the Logen offline partial deduction system [13] to 
that effect (but any other scheme which has a similar effect can be used). 

After this precompilation we can apply ecce to the resulting program, pro- 
ducing the code in Example 4: 

Example 3. 

model_check_saf ety sat 1 2(A). 

/* sat 1 2(A) — > [sat l(A,s(0) ,s(0) ,0,0)] */ 

sat 1 2(A) sat_eu 2 3(A). 

/* sat_eu 2 3(A) — > [sat_eu 2(A,s(0) ,s(0) ,0,0)] */ 

sat_eu 2 3(s(A)) sat_eu 2 4(A). 

sat_eu 2 3 (s (A) ) : -sat_eu 2 5 (A) . 

/* sat_eu 2 4(A) — > [sat_eu 2(A,s(0) ,0,s(0) ,0)] */ 

sat_eu 2 4(A) sat_eu 2 3(s(A)). 

/* sat_eu 2 5(A) — > [sat_eu 2(A,0,s(0) ,0,s(0))] */ 

sat_eu 2 5(A) sat_eu 2 3(s(A)). q 

While this program is hard to read at first, every specialised predicate repre- 
sents a set of reachable markings and the whole specialised program corresponds 
to a coverability graph of the Petri net under consideration (see [14] for more 
details). From the output of ECCE we generate an Isabelle theory representing 
the generated coverability relation. Independent of the particular domain this 
relation is declared as a set of pairs of states: 

consts 

coverrel:: "(state X state) set" 

For each predicate name of a clause in the specialised program, which repre- 
sents a set of states we add a declaration of the form: 

consts 

name : : nat ^ ...^ nat ^ state" 

Thereby the number of parameters of type nat corresponds to the number 
of variables in the head of the clause. The definitions have the form: 

def s 

name-del : "name list of variables = term" 

For our purposes term will be always a tuple of terms built using the unary 
successor function Sue, 0, and variables appearing in the list of variables (the 
number of variables in this list must correspond to the number of parameters in 
the declaration of name). 

Finally, the coverability relation is defined as a set of pairs of states. In the 
specialised program every clause of the form namemi&rgSm') name„(argSn) 
corresponds to such a pair. Formally, in the Isabelle theory each pair is rep- 
resented as a tuple (x,y), where x and y are tuples of terms built by Sue and 
variables of the corresponding list of variables: 
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def s 

coverrel_def : "coverrel = 

{(x,y). 3 listi of variables, x— stateu A y= statei 2 } 

U {(x,y). 3 list 2 of variables, x— state 2 i A y= state 22 } 

U {(x,y). 3 listm of variables. x= statemi A j— statem 2 }" 

The theory generator (cf. [9]) produces automatically the specification of the 
coverability relation from the specialised program. 

Example 4- The following theory was generated by the theory generator [9] from 
the program of Example 4: 

consts 

coverrel:: "(state X state) set" 

sat__l__2 : : "nat ^ state" 
sat_eu__2__3 : : "nat ^ state" 
sat_eu__2__4 : : "nat ^ state" 
sat_eu__2__5 : : "nat ^ state" 
def s 

sat__l__2_def : "sat__l__2 A = (A, (Sue 0) , (Sue 0),0,0)" 
sat_eu__2__3_def : "sat_eu__2__3 A = (A, (Sue 0) , (Sue 0),0,0)" 
sat_eu__2__4_def : "sat_eu__2__4 A = (A, (Sue 0),0,(Suc 0),0)" 
sat_eu__2__5_def : "sat_eu__2__5 A = (A,0,(Suc 0),0,(Suc 0))" 
coverrel_def : "coverrel = {(x,y). 3 A. x=(sat__l__2 A) 

A y= (sat_eu__2__3 A)} 

U {(x,y). 3 A. x= (sat_eu__2__3 (Sue A)) 

A y= (sat_eu__2__4 A)} 

U {(x,y). 3 A. x= (sat_eu__2__3 (Sue A)) 

A y= (sat_eu__2__5 A)} 

U {(x,y). 3 A. x= (sat_eu__2__4 A) 

A y= (sat_eu__2__3 (Sue A))} 

U {(x,y). 3 A. x= (sat_eu__2__5 A) 

A y= (sat_eu__2__3 (Sue A))}" 

□ 

5 Proof Scripts 

In this section we demonstrate how we can prove theorems using Isabelle/Isar 
and how we can write proof scripts for automatic execution. Thereby we focus 
only on some of the “execution style” proof commands of ISABELLE/Isar. These 
commands can be considered to be the classical way of writing Isabelle proofs 
although the actual Isabelle proof methods are wrapped within the ISAR lan- 
guage. Note however that ISAR allows also a more “mathematical style” notation 
of proofs than the one we use here (see the Isabelle/Isar Reference Manual for 
details). 
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Furthermore we discuss only the proof methods we are going to apply in 
order to solve the verification task of ecce. Keep in mind that Isabelle/Isar 
provides a much wider range of methods. 

The proof mode of Isabelle/Isar is initiated by executing a lemma. When 
entering the proof mode Isabelle/Isar generates a single pending subgoal con- 
sisting of the lemma to be proven. The list of subgoals can be altered, mainly by 
executing proof methods. Proof methods are executed using the proof command 
apply. Thereby the list of subgoals defines the proof state. The proof mode can 
be left by executing done in the case that there are no pending subgoals (the 
proof state is the empty list of subgoals, in which case Isabelle/Isar prints No 
subgoals ! ). 

Note that all proof methods described below only transform the first sub- 
goal of the proof state. For finding a proof this may be inconvenient. Therefore, 
Isabelle/Isar provides commands to change the order of the subgoals. How- 
ever, our aim in this paper is the automatic execution of proof scripts, not their 
interactive development. 



Rewriting. To rewrite a subgoal using existing definitions and lemmas auto- 
matically we may execute Isabelle’s simplifier: apply (simp). For the simpli- 
fier to automatically attempt to use new defintions and lemmas they have to be 
accompanied by the option [simp] . Such defined simplification rules are then 
applied from left to right. However, we have to take care if we define simplifica- 
tion rules in such a way as they may slow the simplifier down considerably or 
even cause it to loop. Instead of defining a general simplification rule we may 
also use the simplifier to only apply certain, explicitely stated definitions. E.g., 
the execution apply (simp only: r_def) causes to rewrite using the definition 
of r only. 

Introduction and Elimination. Based on reasoning using natural deduction 
there are two types of rules for each logical symbol, such as V: introduction rules 
which allow us to infer formulas containing the symbol (e.g. V), and elimination 
rules which allow us to deduce consequences of a formula containing the symbol 
(e.g. V). 

In Isabelle an introduction rule is usually applied by apply (rule r). As- 
sume r being a rule of the form: 

Pl,...,Pn 

Q 

where Q is a formula containing the introduced logical symbol while the 
formulas Pi,. . . in the premise do not. Then, if r is applied as introduction 
rule the current first subgoal is unified with Q and replaced by the properly 
instantiated Pi,. . . ,P„. 

An elimination rule is usually applied using apply (erule r) . Assume r being 
a rule of the above form and the current first subgoal of the form Ai, . . . , Am 
S. Then, if r is applied as elimination rule S is unified with Q and some Ai is 
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unified with P\ . The old subgoal is replace by n — 1 new subgoals of the form 
Ai, . . . . ,.,Ara Pk with 2 < k <n. 

In our verification proofs we will use explicitely only the elimination rules 
disjE for disjunction and paths . induct for induction over the length of paths. 



Automatic Reasoners. Most classical reasoning of even simple lemmas can 
require the application of a vast amount of rules. To simplify this task Isabelle 
provides a number of automatic reasoners. Here we will make use of blast 
which is the most powerful of Isabelle’s reasoners. Additionally, we will em- 
ploy clarify which performs obvious transformations which do not require to 
split the subgoal or render it unprovable. The method clarify and the explicit 
application of the elimination rule disjE (see above) was necessary to tune the 
proof process. This tuning was necessary to complete the verification proofs of 
even very small Petri nets using the available computing resources. 

Additionally to the two classical reasoners we also employ the simplifier simp 
as an automatic proof tool as it can also handle some arithmetics. Furthermore, 
for some cases in our verification task simp succeeded faster than blast if it was 
able to eliminate a subgoal at all. 



Scripts. To improve the handling of large proofs and to allow a higher flexibility 
of a proof proof scripts can be extended by the following operators: 

— methodi , . . . ,methodn'. a list of methods represents their sequential execu- 
tion; 

— (method): mainly used to define the scope of another operator; 

— method?: executes method only if it does not fail, 

— methodi I . . . Imethodn'- attempts to execute methodk only if each methodi 
with i < k failed; 

— method+: method is repeatedly executed until it fails. 

For our verification task the lemma and proof script are generated automat- 
ically by the theory generator [9]. The execution of the script in the example 
below is illustrated in the next section. 

Example 5. The following lemma and script corresponds to the one automati- 
cally generated by ecce for the Petri net specification of Example 1: 

lemma "1 £ paths 3 y. ( (hd l),y) £ coverrel" 

apply (erule paths . induct) 
apply (simp only: start_def 

coverrel_def ) 

apply (simp only: sat 1 2_def 

sat_eu 2 3_def 

sat_eu 2 4_def 

sat_eu 2 5_def ) 



apply (simp) 
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applyCsimp only :trans_def ) 

apply (clarify) 

apply (( (erule disjE)?, 

simp only: coverrel_def , simp, 

((erule disjE)?, 

simp only: sat 1 2_def 

sat_eu 2 3_def 

sat_eu 2 4_def 

sat_eu 2 5_def , 

simp I blast )+)+) 

□ 



6 Verifying ECCE 

In this section we illustrate the automatic verification of the ECCE output by the 
Isabelle system. To this end the theory, lemma and proof script as generated by 
ECCE for the Petri net of Example 1, are executed (the complete input consists 
of the Isabelle specifications of Example 1, Example 5, and lemma and proof 
script of Example 6). Full details can be found in the technical report [9]. After 
this, we can also apply the steps required to prove the lemma for transition 
tl in a similar fashion to the remaining transitions. The following proof script 
attempts precisely this. Again, the elimination rule disjE is not applicable for 
the last transition. Hence, we perform a test using ? before applying this method 
in the first line. 

apply (( (erule disjE)?, 

simp only: coverrel_def , simp, 

((erule disjE)?, 

simp only: sat 1 2_def 

sat_eu 2 3_def 

sat_eu 2 4_def 

sat_eu 2 5_def , 

simp I blast) +)+) 

For our example all cases could be verified, hence Isabelle answers: 

No subgoals ! 

□ 

Consequently, the coverability relation generated by ECCE for the Petri net 
of Example 1 covers indeed all states reachable by any path (under the condition 
that the theory generated by the automatic theory generator as implemented in 
ECCE is correct). 



Automatic Generation of Hypotheses. Instead of defining the coverability 
as a relation as illustrated in Subsection 4.2 we may view the coverability graph 
as an inductive definition of a set of states which covers the actual state space of 
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the Petri net. Similarly, instead of using the concept of paths, we may directly 
specify the set of reachable states inductively in Isabelle/Isar. Full details can 
be found in the technical report [9] . 

However, we did not yet succeed in implementing a complete proof script 
using this rule as the search for the appropriate alternative subgoal has to be 
controlled by the proof script. Within the execution oriented proof style we have 
focused on Isabelle/Isar does not seem to provide enough control without 
implementing new proof tactics on Isabelle’s ML-implementation level. 



7 Conclusion and Further Work 

We have shown the similarity between controlling partial deduction and induc- 
tive theorem proving. We have formally established a relationship between the 
program specialiser ecce and the proof system Isabelle when applied to ver- 
ifying infinite state Petri nets. We have shown that verification of ECCE output 
using the proof system Isabelle can be achieved for small nets. The execution 
of the proof script of Section 6 on a Pentium 11/400 needed about 90s and the 
underlying PolyML required 80MB of memory. However, as further experiments 
with a net containing 14 places and 13 transitions reveiled, more specific proof 
methods have to be employed as the use of the method blast required more 
than the available 200MB of main memory and therefore had to be canceled. 
One way of tuning the proof process further is by restricting the number of rules 
potentially applied by blast. However, while rules can easily be removed from 
and added to the list of simplification rules in Isabelle/Isar, a similar simple 
manipulation of the “blast rules” without rewriting underlying Isabelle proof 
tactics seems not possible. An indirect way of restricting the search space of 
blast could also be to derive the theory PN not from Main but from (sets of) 
more basic theories. 

A way of improving the readability of the proof script could be to employ the 
mathematical proof style instead of the execution oriented style. In the math- 
ematical proof style higher-order pattern matching can be used to control the 
proof. This may also increase the flexibility of the proof significantly, in partic- 
ular if the results have to be generalised for other specifications than those of 
Petri nets. 

Finally, for Isabelle to automatically generate the coverability relation from 
the specification of the Petri net we believe that it is necessary to implement a 
new proof rule/proof method at Isabelle’s implementation level which allows 
to automatically backtrack over potential hypotheses which are more general 
than the subgoal to be shown. Another option worth exploring might be to 
attempt to define a proof scheme using the higher-order pattern matching of 
Isabelle/Isar, which performs the abstraction on proof level: E.g., if a state 
description matches a certain pattern we attempt to prove a lemma concerning 
a similar pattern where a constant is replaced by some variable. 

Finally, to use program specialisers for proving more complicated inductive 
theorems one probably needs a tighter integration of (conjunctive) partial de- 
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duction with abstract interpretation, e.g., as detailed in [6, 22, 11]. We hope that 
future research will uncover more exciting parallels between inductive theorem 
proving and program specialisation. 
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Abstract. We present a method for patching faulty conjectures in au- 
tomatic theorem proving. The method is based on well-known fold- 
ing /unfolding deduction rules. The conjectures we are interested in 
here are implicative formulas that are of the following form: VT 4>{x) = 
VT 3Y r{x,Y) 2\(a:). A faulty conjecture is a statement VT 4>{x), 
which is not provable in some given program T, defining all the predi- 
cates occurring in (j>, i-e, M{T) ^ VT where M{T) means the least 
Herbrand model of T, but it would be if enough conditions, say P, were 
assumed to hold, i.e., M{T UV) \= VT (j){x) P, where P is the defini- 
tion of P. The missing hypothesis P is called a corrective predicate for 
(j>. To construct P, we use the abduction mechanism that is the process 
of hypothesis formation. In this paper, we use the logic based approach 
because it is suitable for the application of deductive rules. 

Keywords: Corrective predicate, program synthesis, theorem proving, 
implicative formulas, folding/ unfolding rules, abduction. 



1 Introduction 

Classical proof techniques can be seen as simplification methods, i.e. conjectures 
are transformed to trivial ones, true. Unfortunately, sometimes the proof ends 
up with an unprovable or a false conjecture. In general, a theorem prover will do 
nothing more but reject this conjecture. However, in many cases it is strongly 
interesting to know why the conjecture is false, and how it can be corrected. 

In this paper, we are interested to correct faulty conjectures by synthesizing 
the missing hypotheses. To do that, we consider a theory T of definite logic 
programs (Horn clauses) and conjectures, called implicative formulas, of the 
form Va; 3Y r(x,Y) ^(x), where P and A are conjunctions of atoms. Given 
a conjecture (j)^^/x 3Y r{x,Y) ^ A{x) that is not valid in the least Herbrand 
model of T, i.e., 

M{T) ^ VT 3Y r{x,Y) ^ A{x) 

our aim is to turn </> into a theorem, by inserting assumptions into the right-hand 
side of 4>. An assumption is represented by a (corrective) predicate say P defined 
by some program V. P is said to be a corrective predicate of (j) if we have: 
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M{TyJV) h Vx 3Y r{x,Y) ^ A{x),P{x) 

The definition of the corrective predicate P is obtained by proof-as-program 
paradigm [8] . To construct P, we exploit information derived from a failed proof 
attempt of (j). To do that, we use a theorem prover, a set of inference rules. 
This prover is particularly suitable to prove recursive definitions or to synthesize 
corrective predicates. This predicate synthesis may be viewed like a kind of 
abduction [14,9]. 

The correction of conjectures has various applications. The patching faulty 
conjectures can be useful if the formula to be patched has been obtained by an 
overgeneralization technique otherwise the original (true) conjecture cannot be 
proved. It is then necessary to correct the generalized formula [2], [16] see section 
4.1 for more examples. In [7], corrective predicates are also used to extend classes 
of formulas where inductive validity is decidable. 

Here is a simple example illustrating our patching faulty conjectures method. 



1.1 Example 

Suppose that PLUS is the following program: 



plus(Q,x,x) -fr- 

plus(s(x),y, s(z)) ^ plus(x, y, z) 

nat(0) ^ 

nat(s(x)) ^ nat(x) 



where s and 0 are constructors. The atom plus(x, y, z) is true if z = x + y and 
nat(x) is true if x is an integer. Let us consider the following specification for 
the subtraction function in natural numbers: given two natural numbers v and 
w, find U such that v + U = w. To this specification corresponds the implicative 
formula : 



Vu Vic 3U plus(v,U,w) -fr- nat(v) , nat(w) (1) 

which is false, as we discover while attempting to prove it, for example there 
is no U verifying 2 + U = 1. Nevertheless, there are particular values for the 
universally quantified variables for which the formula (1) is true. It is interesting 
to know these values of v and w. To do that, the formula (1) is associated with a 
corrective predicate P(v, U, w). First at all, we try to prove (1) and to keep track 
of substitutions on P. After some unfolding steps on (1), we get the following 
formulas (without quantifiers): 



plus(0,U,w) ^ nat(w) 
plus(s(v), U, 0) ^ nat(v) 
plus(v,U,w) ^ nat(v),nat{w) 



( 2 ) 

( 3 ) 

( 4 ) 
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— formula (2) is true with the existential substitution {U/w}] and its corre- 
sponding predicate is the unit clause P{Q,w,w) 

— while formula (3), it is fully false, then its corresponding corrective predicate 
is set to false. 

— formula (4) is the same as formula (1), which plays the role of the induction 
hypothesis. An obvious folding step between (4) and (1) allows us to yield the 
formula true, and the following recursive clause for P : P(s{v),U, s(w)) •<— 
P{v, U, w). 

We have then synthesized a definition, say P, of P: 

P(0, w, w) ^ (5) 

P{s{v),U, s{w)) ^ P{v,U,w) (6) 



Note that in the clause (6) occurs the existential variable U. We have to 
eliminate in some way this variable. For instance, a truncation of P w.r.t. its 
second argument yields the following program P': 

P'(0,w) ^ 

P'(s(v), s(w)) P'(v,w) 



We remark that P' is the predicate < over natural numbers, and we have 
M{PCUS up') ^ Vu Vw 3U plus{v,U,w) nat{v),nat{w),P'{v,w). 



1.2 Proof Method 

We present an extension of the systems defined in [18, 10] so as to make it capable 
of dealing with faulty conjectures using a synthesis mechanism. The system 
presented here uses deduction rules, that include unfolding and folding, that 
allow us to prove implicative formulas. Intuitively, unfolding is an extension of 
SLD-resolution whereas folding represents deductive reasoning. Indeed, whereas 
an unfold step replaces a term that “matches” the conclusion of a definition in 
the program by the corresponding hypothesis, a folding right (resp. left) step 
replaces a conjunction of atoms that match the hypothesis (resp. conclusion) of 
an induction hypothesis by the corresponding conclusion (resp. hypothesis). 

In order to synthesize the definition of the corrective predicate, we propose 
an extension of the logic program extraction method of Fribourg [5]. Fribourg 
described a method for generating programs from (true) conjectures. The method 
of Fribourg makes use of an extended form of SLD-resolution and a form of 
structural induction. Our method does not use explicit induction and inductive 
rules of inference [4], but the folding rules are able to perform some induction 
proofs and to synthesize some recursive predicates. 

So if our system is used to prove a given faulty conjecture, it will build a 
corrective predicate P, and if it is used to prove a true conjecture, the corrective 
predicate true will be generated. 
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The rest of the paper is structured as follows: section 2 presents some no- 
tations and definitions, in section 3 we describe our proof system. Section 4 
presents an example illustrating the patching process and some results of ex- 
perimentation. The last section is a comparison with the related works and a 
discussion. 

2 Preliminaries 

Throughout the paper, F, A and A denote conjunctions of atoms; <f>, tt and tt' de- 
note implicative formulas; A and B denote atoms and 9, a denotes substitutions. 
In all formulas, existentially quantified variables are distinguished from universal 
variables by giving them upper-case letters. A program is a set of definite clauses, 
programs are denoted by calligraphic letters: F, V,. . .. An implicative formula 
is a first-order formula of the form F(x,Y) •<— A(x), where x and Y are vectors 
of universally and existentially quantified variables respectively, and where no 
variable of Y occurs in A. The sub-formula A (resp. F) is the hypothesis (resp. 
conclusion) . mgu means “most general unifier” . 

Definition 1 (Corrective predicate). Let 4> : F{x,Y) ^ A{x) be a implica- 
tive formula, T the program defining the predicates occurring in 4>, P a predicate 
and V a program defining P. 

— P is a corrective predicate of 4> iff A4(F AV)\= F(x,Y) A(x), P{x) 

— P is a maximal corrective predicate of (f> if for all corrective predicate P' of 

4>, we have: V) ^ Va; P{x) ^ P'{x) where V is a program defining 

P'. 

Definition 2 (Partial correctness [5]). Let 4> : F{x,Y) ^ A{x) be an 

implicative formula whose predicates are defined by the program T. Let V be a 
program defining a predicate P. The program V is partially correct for T with 
respect to (f iff MfT UP) |= Vx VF F{x,Y) ^ A{x), P{x,Y). 

Remark 1. Let us note that in the definition of “Partial correctness” the exis- 
tential variables Y of the formula (f> are universally quantified, the truncation of 
the predicate P with respect to the variables of Y will allows us generally to 
obtain a corrective predicate. 



3 Proof System 

Let P be a definite program, and tt an implicative formula. To prove that 
A4(T) ^ 7T, we apply deduction rules in tt step by step until we get trivial 
formulas. We describe the proof process and synthesis of corrective predicates 
as a proof tree. The nodes of the proof tree are labelled by < tt | P > where tt is 
a formula and P is a predicate associated with tt. The root of the proof tree is 
labelled by the initial formula and each branch of the proof tree is marked by a 
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deduction rule. A deduction rules generates a set of pairs namely {< tti \ Pi >} 
from a given pair < tt \ P > and also some Horn clauses which establish the 
relationship between the predicates P and Pi. The synthesized program is the 
set of clauses generated during the proof. 

3.1 Deduction Rules 

Definition 3 (Folding right or CUTR). Let tti : T ^ Z\i,Z \2 and ttq : 
A ^ n be two formulas satisfying the following eonditions : 

— 9 is a substitution such that 119 = A\ 

— for any local variable x in II, x9 is a variable and does not occur other than 
in P9 

— 9 replaces different local variables in U with different internal variables in 
A,. 

CUTR yields the formula tt 2 defined as follows: 



< TTo 


■■ {A ^ n)\ 


Po > 


< 7Ti : 


{P^Ai,A2) 


1 Pi > 




iCUTR 




< 7T2 : 


{P^A9,A2) 


1 P 2 > 



The clause Pi <— Pq9, P 2 is generated and added to the synthesized program. 

Remark 2. The formula tto has generally the role of the induction hypothesis 
and it is necessary to verify that ttq is smaller than tti w.r.t. a well-founded 
ordering. 

Proposition 1. The rule CUTR preserves partial correctness. 

Proof. We suppose that the formulas T ^ A9,A2,P2 and Pi ^ Pq9, P 2 hold, 
we have to prove that the formula P ^ Zii, A 2 , Pi holds in the least Herbrand 
model of the program defining its predicates. Let AiGh, A 20 q, PiCTo be ground 
instances of Z\i, A 2 and Pi respectively, we must prove that P(Jo holds. 

— from Pi9o and the only-if part of Pi ^ Pq6*, P 2 it follows that Po9ao and 
P 2 (To hold 

~ according the definition of CUTR, we have 119 = Ai, then II9ao = Aiao. 

— From the induction hypothesis A ^ II, Pq and from the conjunctions II9ao 
and Po9ao that hold, we have A9ao. 

Finally from the formula P •<— A9, A 2 , P 2 and the three following conjunctions 
A9(Jq, A 2 <Jq and P 2 CT 0 that hold, we can conclude that Pctq holds too, Q.E.D. 

Likewise, we define the rule of folding left. 

Definition 4 (Folding left or CUTL). Let TTi : Ti,r 2 ^ A and ttq : A -h- 

n be two formulas satisfying the following conditions: 
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— 9 is a substitution such that A9 = A 

— in A, z9 is a variable and does not occur other than in A6 

— 9 replaces different internal variables in A with different internal variables 
in A . 

CUTL yields the formula tt 2 defined as follows: 

< TTo : {A^ n) \ Po> 



< 7Ti : (A, A ^ A) I A > 

I CUTL 

< 7T2 : (i76»,A ^ Z\) I P2 > 

The clause Pi ^ Pq9, P 2 is generated and added to the synthesized program. 
Proposition 2. The rule CUTL preserves partial correctness. 

Proof, the proof is similar to CUTR. 

Definition 5 (Unfolding right or NFI). Let T be a program, ttq : P ^ A, A 

a formula and C = {c\, . . . ,Ck\ the set of clauses ofT such that Ci : Bi ^ Ai 
and there exists a substitution 9i = mgu{Bi,A). NFI yields the formulas tti 
( 1 < i < k) defined as follows: 

< 7To : (-T -i— Z\, A) I A) > 

I NFI 

< TTi : (U <— A, Ai)9i I A > 

The clauses Po9i ^ Pi (1 < i < k) are generated and added to the synthesized 
program. 

If C = 0, i.e., M.{T) y=- A, then the formula ttq is reduced to the (true) 
formula P <— false and the unit clause Pq ^ is generated. 

Example 1. Let ttq : plus{u, v, w) plus{v, u, w) \ Pq{u,v,w) be a formula 
to be corrected. NFI yields the two following formulas: 

7Ti : plus{u, 0, u) <— I Pi(u) 

7T2 : plus{u, s(v), s(w)) <— plus(u, V, w) I P 2 {u, V, w) 

The relationships between the predicates Pq, Pi and P 2 are defined by the fol- 
lowing clauses: Po{u, 0, u) ^ A(u) and Pq{u, s { v ), s { w )) ^ A(m, v , w ). 

Proposition 3. The rule NFI preserves partial correctness. 

Proof. We have to prove that if for all i G [1, k] the formulas P9i G- A9i, Ai9i, 
Pi and the clauses Po9i G- Pi hold then the formula P ^ A, A, Pq holds. 

It is sufficient to note that the formulas P9i G- A9i, Ai9i, Pi may be obtain 
from the formula P ^ Z\, A, Pq by the rule NFI by selecting successively 
the atoms A and Pq. We have the expected result because the rule NFI is 
equivalence-preserving [11]. 




26 



Francis Alexandre, Khaled Bsai'es, and Moussa Demba 



We define a rule that simplifies an atom in the conclusion of an implicative 
formula. 

Definition 6 (Simplification rule). Let tt : A, F B, A be a formula such 
that there exists 9 satisfying A0 = B and 9 substitutes only existential variables 
of A. The simplification rule applied on tt yields the formula tt' and is defined 
as follows: 



<7T : {A,r ^ B,A) \ P > 
iSIMP 

< tt' : {P9 ^ B, A) \ P' > 

The clause P9 ^ P' is generated and added to the synthesized program. 
Example 2. 

< TT : plus{ul,y, X),plus{X, z,u3) <— plus{ul,y,t), plus(t,z,u3) \ P> 

iSIMP 

< tt' : plus{t, z,u3) <— plus{ul,y,t), plus{t, z,u3) \ P' > 

The rule SIMP can be applied on tt with 9 = {X/t} and yields tt' . The 
clause P{ul,y,t, z,u3,t) ^ P'{ul,y, z,u3,t) is then generated. 

Definition 7 (Unfolding left or DCI). Let P be a program and ttq : P,A^ 
A be a formula. Let C = {ci, . . . ,Ck} be the set of clauses of P such that 
Ci : Bi ^ Ai and there exist existential substitutions 9i = mgu{Bi, A) (9i does 
not modify universal variables). The rule DCI yields the formulas TTi (1 < i < k) 
defined as follows: 

< ttq : (P, A <— A) I Pq > 

I DCI 

< TT, = ((P, A)9, ^ A) I P,> 

The clauses Po9i ^ Pi (^ < i < k) are generated and added to the synthesized 
program. 

Definition 8 (POSTULATE). Let < TT : P ^ \ P > be a pair (where P is a 

corrective predicate associated with the formula P <—); the rule of POSTULATE 
applied on tt yields the formula true and generates the clause P <— P which is 
added to the synthesized program. 

Remark 3. This rule allows us to stop the proof with tt as a leaf of the proof tree 
and to establish a relationship between the new synthesized predicate, namely 
P, and the primitive predicates (i.e. these occurring in P). 

The rules SIMP, DCI and POSTULATE preserve partial correctness [5] 
and [1]. 

The FAILURE rule allows us to detect the fully false conjectures. 
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Definition 9 (FAILURE). Let 'T he a program and < tt : F ^ A |P>a 
pair where P is the corrective predicate associated with the formula F ^ A. If no 
atom of F is unifiable with no clause head of the program T and that Ai{T) [= A 
then the rule FAILURE yields the couple < false \ false >. 

<F ^ A \P> 

I FAILURE 
< false I false > 



The predicate P is set to false. 

Proof. The rule FAILURE preserves partial correctness. It sufficient to note 
that the formula F ^ A, P holds, this is true because P is false. 

Remark 4- This rule allows us to eliminate all the clauses of the synthesized 
program which contain the predicate P in accordance with the negation as failure 
principle. 

Example 3. Going back to the formula (3) of our introductory example : 
plus{s{v),U,0) <— nat{v). The atom plus{s{v) ,U is false, because, in one 
hand it cannot be reduced using the program VCUS and on the other hand we 
have M.(fPClAS) ^ Vu nat{v). The formula plus{s{v),U,0) ^ nat{v) is then 
(fully) false and its corresponding corrective predicate is set to false. 

3.2 Corrective Predicate 

The preservation of partial correctness for all the deduction rules guarantees the 
construction of a corrective predicate for the universally quantified implicative 
formulas. For the existentially quantified formulas, it is necessary to truncate the 
synthesized predicate with respect to the existentially variables. The following 
proposition gives a sufficient condition to get a corrective predicate. 

Proposition 4. Letir : F{x,Y) ^ Afx) he a conjecture, T the program defining 
the predicates occurring in tt and P the predicate associated with tt. Let V he the 
synthesized program obtained by using the previous deduction rules, V defines P. 
Let P' be the predicate symbol obtained from P by truncating it with respect to 
its existential variables and V the resulting program defining P' . If we have 

M{TyJV\JV')'^3YP{x,Y)^A{x), P'{x) (7) 

then P' is a corrective predicate of tt. 

Proof. From the partial correctness of P we have 

M{TLIV) h VxVF T(x,F) ^ Z\(x), P{x,Y) 

and the condition (7) gives 

MITUPUP') FVx3FP(x,F) ^ A{x), P'{x) 
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it follows obviously that 

M{TyJV') \=yx3Yr{x,Y) ^ A{x), P'{x) 

this expresses that P' is a corrective predicate of the formula tt. 

Remark 5. The condition (7) may generally be proved by using the rules CUTR, 
CUTL, NFI, DCI and SIMP, and the proof is often straightforward. 

The termination of the method we propose, can be expressed by the following 
formula: 

M{T) h yx3YP{x,Y) ^ A{x) 

The termination is not guaranteed because of folding rules (CUTL and CUTR) . 
This is due to the fact that the rules of folding do not preserve equivalence. If it is 
supposed that the predicates specify functions, the folding rules are equivalence- 
preserving and it is possible to show the termination of our method. 



4 Experimentation 

4.1 Example 

The following program defines the multiplication of the natural numbers. 
mul{0,m,0) ^ 

mul{s{n),m,r) ^ mul{n,m,u), plus{u,m,r) 

plus{Q,x,x) -fr- 

plus{s{x),y, s(z)) ^ plus{x, y, z) 

nat{0) ^ 

nat{s{x)) -fr- nat{x) 

We consider the following false conjecture mul{U,v,w) ^ nat{v), nat{w) 
and Pl{w,v,U) the associated predicate. The figure 1 shows the proof tree of 
this conjecture. 

The formulas occurring at the leaves of the proof tree are the following: 

(11) nat{v) , nat{u2) nat{v),nat{u2) 

(15) nat{V5),plus{V5, s{x),0) ^ nat{x) 

(16) nat(O) <— 

(17) mul(U, 0,0) <- 

(19) <— nat(x) 

(20) mul(N, s(x),V8),plus(V8, s(x),0) ^ nat(x) 

The formulas (11), (16), (17) and (19) are true, and the formulas (15) and 
(20) are totally false. Finally, the program defining the predicates is made of the 
following clauses 1 to 19. 
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(1) mui(U,v,w) <- nat(v),|nat(w) 

(2) mul(U,v,0) nat(v)| 

NFI 

K-nat(x) (17) mul(U,0,0) <- (4) 





DCI 



mul(N,v,Vl) 



<- nat(v) 
nat(x) 



<- nat(v), 



DCI 



plus(Vl,v,s(x)) nat(x) 
CUTL with 1 



( 1 9) <- nat(x) (20) mul(N,s(x),V8) 

pius(V8,s(x),0) <- nat(x) nat(Vl) <- fnat(v^ 



FAILURE 



false 



plus(Vl,v,s(x)) nat(x) 
SIMP 



' M6) 1 > v,s(x)) <- | nat(x) 

nat(VI) 



NFI 



(8) nat(VI), pIus(Vl,v, s(s(u2)) <- nat(u2) (7) nat(Vl), plus(Vl,v,s(0)) <-nat(v) 

nat(v) 



DCI 



DCI 



(9) nat(s(X)) pIus(X,v,s(u2)) <- nat(u2) 



(12) nat(s(X) pIus(X,v,0) <- nat(v) 





nat(v) 

DCI 




DCI 

' 


'(10) nat(V2), pIus(V2,v,s(u2)) <- nat(u2) 


(13) nat(V5), pIus(V5,v,0) <- nat(v) 




nat(v) 

CUTL with 6 







(11) nat(v), nat(u2) <- nat(u2), nat(v) 



NFI 



(14) nat(V5), plus(V5,0,0) <- (15) nat(V5), plus(V5,s(x),0) <- nat(x) 

DCI FAILURE 



(16) nat(O) <- 



false 



Fig. 1. Proof tree 
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(1) Pl(0,w,[/) ^ P2{v,U) 

(2) Pl(s(a;), V, U) ^ PS{x, v, U) 

(3) P3(x, V, s{N)) ^ Pa\x, V, FI, N) 

(4) P4(x, V, FI, N) ^ P1(F1, V, N),P5{x, v, FI) 

(5) P5(x, V, FI) ^ P6{x, V, FI) 

(6) P6(0,u,Fl) ^ P7{v,Vl) 

(7) P6(s(u2),v, FI) ^ P8(u2, v, F) 

(8) P8(u2, V, s(X)) ^ P9(u2, v, X) 

(9) P9(u2, V, V2) ^ P10(u2, v, V2) 

(10) P10(w2,?;,F2) ^ P6{u2,v,V2), Pll{u2,v) 

(11) P7{v, s{X)) ^ P12{v, X) 

(12) Pl2{v, F5) ^ P13(w, F5) 

(13) P13(0,F5) ^P14(F5) 

(14) P13(s(a;), F5) ^ P15(x, F5) 

(15) P14(0) ^ P16Q 

(16) P2(0,P) ^P17(P) 

(17) P2(s(x),P) ^P18(x,P) 

(18) P18(x,0) ^P19(x) 

(19) P18(cc, s{N)) ^ P20(x, F8, N) 

A straightforward program transformation by unfolding [19, 15] simplifies the 
synthesized program above as: 

P1(0,0,F10) ^ 

Pl(0,s(ull2),0) ^ 

Pl(s(u54), u55, s(F23)) ^ P1(F1 , m55, F23), P6(u54, u55, FI) 

P6(0,0,s(0)) ^ 

P6(s(ul00), MlOl, s(F51)) ^ P6(ul00, wlOl, F51) 

Once a program is extracted, the “uninteresting” variables in PI can be 
eliminated. For instance, a truncation of PI with respect to its third argument 
yields the following program. 

P'1(0,0) ^ 

P'l(0,s(ull2)) ^ 

P'1(s(m54), m 55) ^ P6(u54 , m55, FI), P'1(F1, m55) 

P6(0,0,s(0)) ^ 

P6(s(u100),m101,s(F 51)) ^ P6(ul00, wlOl, F51) 

The condition of the proposition 4 is expressed by the following formula 
Pl{x,y,U) -ir- nat{x),nat{y),P'l{x,y). It is easy to prove this formula by us- 
ing the previous deduction rules. P'l{x,y) means that y is a divisor of x and 
P(S{x,y,z) : x + y + l = z. 

4.2 Results 

We have tested our method on various implicative formulas. One can see the re- 
sults in the table 1. The missing hypotheses of the non-theorem below have been 
successfully synthesized using the method. Note that the conjecture 5 is only 
valid if X is even, we have then synthesized the predicate even. The table shows 
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Table 1. Examples 



N° 


Conjectures 


Corrections 


Definitions 


1 


sup{x,n) <r- half{x,n) 


x ^ 0 




2 


sup{y, x) •(— double{x, y) 


x ^ 0 




3 


half{y,s{0)) ^ 


y = s^(0) 

or y = s^(0) 




4 


plus{x, Z, y) <— 


P{x) 


P{0,y) ^ 

P{s{x),s{y)) -h- P{x,y) 


5 


eq{x,z) •(— half(x,y),double{y,z) 


P(x,y) 


P(0)^ 

P(s2(a;)) ^ P{x) 


6 


sort{l, 1) <— 


P{1) 


J’(D) ^ 

P{[a\l]) ^ P{l),Q{a,l) 

Q(a, D) ^ 

Q{a, [b\l]) inf (a, b), Q{a, 1) 


7 


even{z) <— plus{x, y, z) 


P{x,y) 


P{0,y) <- even(y) 
P(s(0),j/) even{s{y)) 
P(s^(a;),s^(j/)) ^ P{x,y) 


8 


plus{v, U, w) <— nat{v), nat{w) 


P'{v, w) 


P'(0, w) <— 

P'{s{v),s{w) P'{v,w) 


9 


mul{U,v,w) ■(— nat{v),nat(w) 


P{w, v) 


P(0,0)^ 

P(0,s(u)) <- 

P(s(w),u) <- Q{w,v,u),P{u,v) 
g(0,0,s(0))^ 

Q{s{x),y,s{z)) <r- Q{x,y,z) 



that our method can also be useful if the formula to be patched has been obtained 
by an overgeneralization technique otherwise the original(trMe) conjecture can- 
not be proved. For instance, the generalization of the formula sort{sort{x)) = 
sort{x) leads to an overgeneralization (formula 6) [2]: sort{l, 1) ^ Clearly, 

the conjecture 6 is valid only if the list I is ordered. In this case our method finds 
a candidate corrective predicate P that is equivalent to the predicate ordered, 
and the corrective predicate Q is equivalent to the predicate lessJ,hariMll over 
lists, i.e., the atom Q{a,l) stands for that the element a is less than all the 
elements in the list 1. It is clear that the formula: sort{l,l) ^ list{l), P{1) is a 
theorem by construction. Hence, using the proposed method we may be able to 
prove formulas which are unprovable otherwise. Conjectures (8) and (9) contain 
existentially quantifiers. 
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5 Conclusion 

5.1 Related Works 

Franova et al. [6] have investigated the problem of patching faulty conjectures 
and proposed a method called PreS (predicate synthesis from formal specifica- 
tion) . Their approach is based on the paradigm of predicate synthesis by proofs- 
as-programs. They explained their method by examples. No formal system is 
clearly defined and no system is described. 

Protzen [16] proposed a method which allows to synthesize a corrective pred- 
icate during the proof attempt of a faulty conjecture. His approach is similar to 
ours, but uses rewriting rules and induction rules, he gives some correctness 
results and dealt with universally quantified formulas. 

Also Monroy et al. have introduced a method for correcting faulty conjec- 
tures [13]. However, they only partially deal with the problem of correcting faults. 
For example, they cannot build a corrective predicate, only identify it as long as 
it is present in the working theory. More recently, Monroy proposed in [12] an- 
other method that consists of a collection of construction commands and is able 
to synthesize corrective predicates. His approach is also based on the proofs-as- 
programs paradigm and guarantees the correction and the termination. There is 
a similarity between his predicates and ours, but his predicates are refined in- 
crementally during the proof process. Monroy poses the problem of automation 
of the process and suggests to use a proof planning approach [3]. His technics 
deal with universally quantified formulas. 

5.2 Final Remarks 

We have presented a new method for patching faulty conjectures by synthesizing 
definite programs. The contribution of the paper is mainly the construction of 
corrective predicates by completing failed proof attempts. This method is orig- 
inal because it makes possible to correct formulas comprising of the existential 
quantifiers and it uses the powerful rules of folding. We proved the partial cor- 
rectness of this method. We tested our method successfully on several examples 
borrowed from the literature, and we generally obtain some maximal predicates. 
The proposed method for patching faulty conjectures and extracting logic pro- 
grams is implemented in the functional language OCaml (Objective Caml) [17]. 
So in our implementation, the user has to specify which rules to be applied. The 
full automation of the technique requires some proof strategies. We are investi- 
gating several ways. One is to implement some strategies in order to automate 
our system, a second track is to show that our method is useful in the domain 
of theorem proving, finally we intend to show that our method can be used to 
detect protocol attack. 
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Abstract. Object Oriented Design Frameworks (OOD frameworks) are 
groups of interacting objects. We have formalised them in computational 
logic as open systems of interacting objects. Our formalisation is based 
on steadfast logic programs in the context of open specification frame- 
works. However, we have considered only the static aspects, namely the 
specification of constraints and the correctness of queries (programs that 
do not update the current state). In this paper we extend this static 
model, by introducing actions that update the current state. 



1 Introduction 

In Object Oriented Analysis and Design (OOA&D), the traditional unit of design 
is of course the class. However, the observation that in the real world, design 
artefacts are rarely about single classes, but about groups of objects and the way 
they interact, has led to the introduction of OOD frameworks, which represent 
such groups of interacting objects. It is widely recognised that OOD frameworks 
are better design (and reuse) units than single classes. 

Different characterisations of OOD frameworks as components have been 
proposed, using UML (Unified Modelling Language) [19]), e.g. frameworks in 
Catalysis [7] and Komponents in KobrA [2]. These approaches model OOD 
frameworks as UML subsystems. However, they do not define OOD frameworks 
(or components) precisely or formally. 

A natural candidate for formalising OOD frameworks in UML would be the 
Object Constraint Language (OCL) [22]. OCL aims to become a standard for the 
formal specification of OO systems. It is being formalised in its various aspects 
[17] and there are Java tools (e.g., [6]), but its syntax and semantics are not yet 
fixed in a definitive and stable way. 

Independently, we have been working on the formalisation of OOD frame- 
works in computational logic [12,14]. In [14] we started with a more logically 
oriented formalisation of OO systems, because we believe that computational 
logic can offer a solid base for a formalisation of OO systems (and hence OOD 
frameworks). Moreover, we believe that OCL would benefit from a separate and 
more logically oriented approach. It would inherit a lot of knowledge, like Ab- 
stract Data Types, temporal logic, proof theoretical tools, and so on. We are 
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Fig. 1. 



looking for a situation like the one depicted in Fig.l, where we can design spec- 
ification formalisms for 00 systems, on top of a meta-theory, i.e., a sound and 
general underlying logic formalisation. 

To formalise OOD frameworks as open systems of interacting objects, we 
started from our previous work on steadfast programs in the context of open 
specification frameworks [15]. A specification framework is an open first-order 
theory that formalises a class of intended models. Specification frameworks can 
be instantiated (or reused) by theory morphisms, like in algebraic ADT’s [23], 
and steadfast programs are open programs that correctly instantiate in every 
framework instance. Thus steadfast programs have the properties desired for 
the methods of correctly reusable units, and specification frameworks specifying 
and containing steadfast programs become good candidates for the formalisation 
of OOD frameworks. 

In 00 systems, instances are systems of interacting objects, that we call 
object-level instances. To give a precise definition of object-level instances, while 
preserving the features of open steadfast programs, we designed a three-tier 
approach, with an object, a specification and a meta level. The object level gives 
the semantics for our object-level instances. The specification level allows us to 
specify 00 systems. The meta-level allows us to reason about 00 systems, in 
particular, to reason about steadfast programs. 

Although our aim was not the formalisation of UML, our three-level structure 
turns out to be very close to the multi-level approach of UML. The UML object 
and model levels correspond to our object and specification levels, while our 
meta- level has the role of the meta- model and meta-meta-model levels of UML. 
As a consequence, the approach developed in [14] allows us to formalise class 
and object UML diagrams in the context of computational logic. However, in 
that paper, we could only reason about the open correctness of queries, that is, 
open logic programs that do not update the current system state. In this paper 
we extend our approach by adding the ability to specify programs that update 
the current state. Moreover, we generalise our three-tier approach. We consider 
the meta level and the object level as general meta-theory of Fig.l, and we allow 
many different specification formalisms, to be built on top of it. 

This paper is organised as follows. First we briefly review our past work in 
Section 2, and we discuss the general features of our approach. In Section 3, 
we introduce the object level, and we discuss the object-level semantics. In Sec- 
tion 4, we introduce the meta-level, we introduce projections (suitable semantic 
maps between object and meta levels). All this is used in Section 5, to show how 
intermediate specification formalisms, tailored to different aspects, can be de- 
fined, together with their object- and meta-level semantics. The paper is centred 
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on the basic features of 00 systems, which can provide a basis for important 
aspects like classes, polymorphism and modularity, as briefly discussed in the 
conclusion. 



2 Static Aspects of OO Systems 

In this section we give an overview of the static approach to 00 systems given in 
[14], where 00 systems are formalised on the basis of open steadfast programs 
and specification frameworks [15, 11]. 

A specification framework is an open first-order theory, where we distinguish 
open and defined symbols, and we have two kinds of axioms: constraint and 
definition axioms. The former constrain the possible interpretations of the open 
symbols, and the latter fix the intended meaning of the defined symbols in terms 
of the open ones. It may happen that the meaning of some defined symbols is 
completely fixed, independently from the open symbols. These symbols will be 
called closed symbols, and the axioms fixing their intended meaning will be called 
closed axioms. 

A closed specification framework contains only closed symbols and closed 
axioms. In an open specification framework, the sub-signature of its closed sym- 
bols, together with their closed axioms, forms a closed sub-framework, that we 
will call the (closed) kernel. 

The model-theoretic semantics of closed and open specification frameworks 
is based on isoinitial models [13], and we require the following adequacy [12] 
conditions. 

A closed specification framework T is adequate if it has a reachable isoinitial 
model i. i is unique up to isomorphism and represents the intended meaning of 
the signature of T . For an open specification framework T , a pre-interpretation 
is an interpretation of the open and closed symbols, that interprets the closed 
ones according to the kernel and the open ones according to the constraints. T 
is adequate if for every pre-interpretation j, there is a j-isoinitial model of T, in- 
dicated by is unique up to isomorphism and gives the interpretation of the 

defined symbols that corresponds to j. The intended models of T are the models 

determined by the pre-interpretations j. Finally, specification frameworks can 
be built incrementally, by means of adequate extensions [11]. 

Example 1. First-order arithmetic MAT'is a closed specification framework. The 
standard structure M of natural numbers is the (unique up to isomorphism) 
isoinitial model of MAT. It is the kernel of the following open framework, which 
axiomatises lists with generic elements X and a generic total ordering <l on A: 

SpecFramework £IiST(A, <) with kernel MAT', 

ODECL: a : sort, <1 : [A, A]; 

DDECL: ListX : sort, 

nil :[]—>■ ListX; . : [X, ListX] — >■ ListX; 

_@(_, _) : [X, Nat, ListX]; nocc : [X, ListX] — >■ Nat; 

DAxl: FreeMx.{nil, .: ListX); 
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dax2: for x,y : X,i : Nat, I, m : ListX : 

x@(0, 1) O 3y,m. I = y.m A x = y; 
x@{si,l) 3y,m. I = y.m A x@{i,m); 
nocc{x, nil) = 0; 

X = y ^ nocc{x, y.l) = nocc{x, 1) + 1; 

-'X = y — >■ nocc{x, y.l) = nocc{x, 1); 

CONSTR: <1 : TO{<). 

X and <1 are declared as open in ODECL, and the defined symbols are declared 
in DDECL. The constraints CONSTR contain the total ordering axioms TO{<i) for 
<1. The definition axioms DAxl contain the freeness axioms [20] and induction 
for list constructors. dax2 axiomatise x@{i,l) {x occurs at position i in 1) and 
nocc{x, 1) (number of occurrences of cc in 1). 

A specification framework can be instantiated (or reused) by theory mor- 
phisms, and steadfast programs are open programs that correctly instantiate 
in every framework instance. Thus steadfast programs have the properties de- 
sired for the methods of correctly reusable units, and specification frameworks 
specifying and containing steadfast programs become good candidates for the 
formalisation of reusable units. A reusable unit is composed of an open speci- 
fication framework, that formalises the problem context, a set of specifications, 
and a set of steadfast (i.e., correct) open programs. Each program predicate p 
has a declarative specification Sp, and each program P has a program specifi- 
cation P : Stt ^ Ss, which means that P correctly computes the predicates 6 
specified by Ss, whenever it is composed with programs correctly computing tt 
specified by St^. Reusing a unit means instantiating it in the context of reuse. 
The inherited programs can be reused by composing them with other programs, 
according to their specifications. 

Because of the properties of steadfast open programs, in [14] we considered 
reusable units as good candidates for a formalisation of 00 systems. In 00 
systems, instances are systems of interacting objects, that we call object-level 
instances. The first problem here is to give a precise definition of object-level 
instances, while preserving the features of open steadfast programs. We studied 
different possibilities, that we briefly discuss here, together with their correspon- 
dence to UML static diagrams. 

The simpler approach is the renaming approach, that is, the dot notation is 
considered as a renaming notation. This allows a simple and formal definition 
of the instance semantics by theory morphisms. For example, the left-hand side 
of Fig. 2 shows an UML diagram with a Car class and two Car objects; in our 
formalisation the Car class is an open unit, and the the two car objects are 
obtained by instantiating Car by the theory morphisms p,ci and p,c 2 , as shown 
in the right-hand side. At the class level, the attribute .km is open and the 
invariant states that it must be greater than 0 in every instance, pci renames 
.km by cl.km and closes it by the axiom cl. km = 3050, while satisfying the 
invariant. Similarly for the morphism 11 ^ 2 - 

The renaming approach has a clean semantics in terms of theory morphisms, 
but has problems when considering associations and groups of related objects. 
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Car 

kmdnteger 



cl:Car 




c2:Car 


km = 3050 




km = 2300 



Class Car; 

.km : Integer; 
inv kl: .km > 0; 




Obj cl:Car Obj c2:Car 

cl.km = 3050 c2.km = 2300 



Fig. 2. Renaming. 



{inv: Vc : Car* self .owns (c) — >• c.owner{self)} 




Fig. 3. Extra-argument. 



For example, in the invariant inv of Fig. 3 we have to quantify over c, but quan- 
tified renaming does not belong to the syntax and semantics of first order logic. 

For this reason, usually dot is considered as a syntax for introducing c as 
an extra-argument, that is, Vc : Car . self .owns{c) O c. owner (self) represents a 
syntactical variant of Vc : Car. owns{self , c) O owner {c, self). 

But extra-arguments also have problems. For example, by introducing an 
extra-argument, the cl.km attribute becomes a function km{cl) and it cannot 
be completely known unless we know all the Car objects. We believe that this 
is not natural in 00 and in UML object diagrams, where an attribute like km 
should represent a local property of the single, isolated car object. Finally, in 
the extra-argument approach the semantics based on theory morphisms is lost. 

Thus in [14] we came up with a many-level solution, with an object-level, a 
meta-level, and an intermediate specification level. At the object level dot works 
as renaming, each object has its own signature and a system can be considered as 
the union of its objects. This level corresponds to the object level of UML/OCL. 
At the meta-level, dot introduces an extra-argument of a special sort Obj, and an 
00 system S is formalised by a meta-unit U (S) , which allows us to predicate over 
live objects and their classes, and to reason about steadfastness. Its framework 
has the role of the UML meta- and meta-meta-model. Since the syntax of the 
meta-level is redundant, we introduce the intermediate specification level, to 
allow simpler and more natural specifications. It is similar to the UML/OCL 
model level. The three levels are linked by syntactic maps and semantic maps. 
Syntactic maps work in a way similar to theory morphisms, and semantic maps 
have properties similar to the properties of reducts. This guarantees that the 
meta- level can be used to reason about the other levels. 

In the next sections, we extend our previous static model, by introducing 
programs that update the current state and explicit time. 
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3 The Object Level 

We model an 00 system as a possibly distributed set of live objects, that dynam- 
ically evolve through a sequence of states, and collaborate to achieve a common 
goal. Each object has an identity and is created by a template class, which fixes 
the signature of its attributes and methods (programs) and the implementation 
of methods. We may have query, action and activity methods. Each object has 
one template (class) and we write o : T to indicate an object with identity o 
and template T. 

We distinguish between data and objects. For simplicity, we assume that data 
are represented by the ground terms of a predefined data type T>. To represent 
object identities, T> is always assumed to contain a closed framework OBJ , 
axiomatising a special sort OBJ, generated by a denumerable set of constants. 
An object identity is a constant o of sort OBJ. 

3.1 States 

A state can be formalised as a first-order interpretation, or, under the hypothesis 
that each datum is represented by a unique normal ground term of T>, as a 
propositional interpretation. Here we consider the latter case, because it allows 
simpler definitions and is compatible with approaches based on propositional 
temporal logic. Moreover it is not too restrictive in the context of standard 
logic programs, where our propositional interpretations coincide with Herbrand 
models. 

The attribute declarations of a template class T may be constant declarations 
.c : [] — >■ s, or relation declarations .r : [si, . . . , s„], where s,si, . . . , Sn are sorts 
of T>. In the propositional approach ground atoms are considered as proposition 
symbols, and the attribute signature of an object o : T is defined as follows. 

Definition 1. (Object Attribute Signature). Let o : C be an object with class 
C. The attribute signature of o : C is the propositional signature containing 
two kinds of symbols: assignments, of the form o.c is(t), and attribute atoms, 
of the form o.pfti, . . . ,t„), where .c :[]—>■ s and .r : [si,...,s„] are attribute 
declarations of C , and t,t\, . . . ,tn are normal ground terms ofT>. 

A population P is a set of objects, where each object has one template. The 
attribute signature of a population is the union of the signatures of its objects, 
and a state is characterised by a population P and by an interpretation of the 
signature of P. We will indicate by V .Atb the signature of a population P. The 
special syntax o.cis{t) is used only for the assignments. We will call o.c a constant 
oiP.Atb. 

Definition 2. (States). A state of an 00 system is a pair S = (P,I), where 
P is a population and I C P.Atb is a P -interpretation where each constant has 
one assignment. 

^ Classes, interfaces, inheritance and polymorphism can be introduced, but we do not 
have space to consider them here. 
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The proposition symbols of an object o represent its local properties. Their 
current interpretation I represents the current state of o, as shown in Example 2, 
which also illustrates the correspondence of states with UML object diagrams. 

Example 2. The classes of Fig. 3 introduce the following attribute declarations: 

Class Car : navatb : .owner :[]—>■ OBJ; 

ATB : .km :[]—>■ Integer; 

Class Person : navatb : .owns : [obj]; 

where navigation attributes navatb are a special kind of attributes, representing 
links to other objects. 

The attribute signature of a car object c contains the assignments c.km\s{n) 
and c. owner is{o), with o : OBJ and n : Integer. The attribute signature of a 
person object p contains the atoms p.owns{o), with o : OBJ. The navigation 
attributes are declared according to the multiplicities of the class diagram of 
Fig. 3, .owner is declared as a constant (by multiplicity 1 each car has one 
owner), and .owns as a predicate (by multiplicity * a person may own many 
cars)^. 

The object diagram of Fig. 3 corresponds to the state with population P = 
{cl : Car,c2 : Car,john : Person} and interpretation i = {cl.owner is john, 
cl.km is 2500, c2.owner is john, c2.km is HQQQ , john.owns{cl) , phn.owns{c2)} . 

The navigation attributes cl.owner is john and c2. owner is john link cl and 
c2 to john, and john.owns{cl), john.owns{c2) link phn to cl, c2. 

The example introduces the navigation attributes, which link objects. Links 
are defined as follows. 

Definition 3. (Links). Let o,o' : OBJ be two object identities. A link from o 
to o' is an assignment o.nis(o') or an atom o.n(r), where n is a navigation 
attribute and o' occurs in r. 

A link from o to o' allows o to send messages to o' , i.e., call methods of o'. 



3.2 Queries 

Since we are in computational logic, we consider relational queries, that is, a 
template T may contain query declarations of the form .g : [si, . . . , s„], where 
si, . . . , s„ are sorts of T>. 

For every object o : T, the query atoms of o are the ground terms of the form 
o.q{T), and (in the propositional approach) query methods are propositional 
programs. 

Definition 4. (Query Methods). Let o : T be an object and .g be a query declared 
in T. A query method of o for .q is a set of ground clauses of the form o.qp) -fr- B, 
where the body B may contain assignments, attribute atoms and query atoms. 

In OCL, the type of .owns would be Set(Person). 



2 
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An object may call queries or attributes of other objects. In this case, the 
clauses of the query method must be navigable. A navigation from oi to o„ is a 
sequence of navigation atoms oi.A^i, . . . , Ok-Nk such that, for 1 < f < fc, Oi.Ni is 
a link from Oi to Oi+i. Navigability is defined as follows. 

Definition 5. (Navigable Objects and Clauses). Let B he the body of a clause. 
An object o' is B -navigable from o iff o = o', or B contains a navigation sequence 
from o to o' ; a clause o.Q ^ B is navigable iff, for every atom o' .A in B, o' is 
B-navigahle from o. 

For each object o : C and each query .q declared in C, there is a set of clauses 
defining .q in the context of o. To model object collaboration, we consider a 
population as a whole: 

Definition 6. (Distributed Programs). Let S = (0,1) be a state. Let Qs be the 
set of all clauses defining the queries in the contexts of the objects of O; we will 
call Qs the distributed program of S. 

The semantics of Qs can be defined by minimum /-models: 

Definition 7. (Minimum /-models). Let Qs be the distributed program of a 
state S = (0,L); the minimum /-model ofQs is the minimum model ofQsAL. 

We say that a ground query o.q^r) is true (succeeds) in S, iff it is true in the 
minimum /-model of Ps. To indicate that o.q is true in S, we will write S ^ o.q, 
The truth of a set F of compound formulas is defined in the usual way and will 
be indicated by A ^ F. 

Example 3. In the class Car of Example 2 we declare the query .sameOwner : 
[OBj] and implement it by the program 

self .sameOwner (C) self .owner{P) A P.owns{C). 

In the state of Example 2, .sameOwner is represented at the object level (see 
Section 5) by the distributed program 

cl. sameOwner (cl) ^ cl. owner is john /\ john.owns{cl). 
cl.sameOwner{c2) ^ cl. owner is john /\ john.owns{c2). 
c2. sameOwner (cl) ^ c2. owner is john A john.owns{cl) . 
c2. sameOwner (c2) <— c2. owner is john A john.owns{c2) . 

where the first two clauses define .sameOwner in the context of cl and the other 
two clauses define .sameOwner in the context of c2. 

3.3 Actions and Events 

In a template T, an action declaration is of the form .a : [si, . . . , s„] — >■ ACTS, 
where Si, . . . ,s„ are sorts of T> and ACTS is a special sort introduced for the 
actions. The actions of an object o are all the ground terms o.a(r), for every 
action declaration o.a : a — >■ ACTS of o. 
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Definition 8. (Action Methods). Let o : T he an object and .a be an action 
declared by T. An action method of o for .a is a set of update-clauses of the 
form U S, where £ is the enabling condition and U is of one of the forms 
new{o.a,On : T), del{o.a,Od), toT{o.a,o' .c'lsft)) , toT{o.a,o' .pt), toF{o.a,o.pf). 

The enabling condition £ has the syntax of a body navigable from o, and 
states when o.a may occur. It is the same in all the update-clauses of the same 
action. The update clauses define the updates caused by the action o.a. 

When o.a occurs, all the updates of o.a occur simultaneously and give rise 
to a new state. We say that Od is an object deleted by o.a, o„ : T is an object 
created by o.a with template T, o'.cis(t) is an assignment forced to true by o.a, 
o' .pt is an attribute atom forced to true by o.a, and o.pf an attribute atom forced 
to false by o.a. If an assignment o'.cis(t) is forced to true with a new value t, 
then the old assignment is implicitly forced to false. 

A created object is added to the current population, while a deleted one is 
eliminated. To avoid inconsistency, an attribute atom cannot be forced to both 
true and false. If an atom or an assignment is not forced, its truth value is 
preserved. If o'.pt is forced to true by o.a, then o' must coincide with o or be 
one of the objects created by o.a, because we assume that o.a acts locally, i.e., 
it may only initialise the proposition symbols of the new objects and update 
truth values of the proposition symbols of o. For the same reason, a proposition 
symbol forced to false must be an attribute of o. Finally, all the constants o.c of 
a created object must be assigned. 

We allow simultaneous actions. To handle them, we introduce events'. 

Definition 9. (Events). An event e is a set e = {oi.oi, . . . , o^.a^} of actions, e 
is admissible in a state S' = (P,I) iff it contains actions of the signature of P 
and oi, ... ,0k are different identities. 

We associate with each event e the following sets: 

— £e is the conjunction of the enabling conditions of its actions; 

— AfOe is the set of objects created by its actions; 

— is the set of objects deleted by its actions; 

— 7^ is the set of proposition symbols forced to true by its actions; 

— is the set of all attribute atoms forced to false by its actions, all the 

assignments implicitly forced to false by its actions, and all the proposition 

symbols of the objects deleted by its actions. 

Events semantics is formalised by state transitions, as follows. 

We say that e is enabled in a state S = (P,I) iff S' ^ and the objects 
of J\fOe are not objects of the current population P, that is, they are new. 
Moreover, an object can be created by one action. This requirement, together 
with the locality condition, prevents the possibility of inconsistent updates. If e 
is enabled in S = (P,I), then it may fire a transition (P,I) e i— (P',P): 

Definition 10. (00 State Transitions). For every state (P,I) and every ad- 
missible event e enabled in it, the firing of e produces the state transition 

(P,I) ((PUAfO,)\m,(IU7;)\A-,) 
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Example 4- The event e = {pl.selb{cl, pO) , p0.buip{cl, pi) , cl.sold{pl, pO)}, con- 
taining the actions specified below, represents a contract of purchase. 

toF {pl.sells{cl, pO) , pl.owns(cl)) pl.owns(cl). 
toT{p0.bu]p{cl,pl),p0.owns{cl)) <— 
toT{cl.sold{pl, pO) , cl.owner is pO) ^ 

Starting from the state with population cl : Car, pO,pl : Person and interpreta- 
tion cl.owner is pi, pl.owns(cl), the corresponding transition leads to the state 
with the same population and interpretation cl.owner is pO, p0.owns{cl). 



3.4 Observation Sequences, Activities, Time and Space 

We assume that we can ideally observe the system at successive observation 
times ti, . . . , t„, . . in such a way that no two consecutive actions o.oi and 0.02 
by the same object o occur in a single time interval ti, ti+i. Under this hypothesis 
an observation sequence can be modelled as a sequence of state transitions. 

Definition 11. (Observation Sequences and Behaviours). An observation se- 
quence is a sequence So cq Si ei 1 — S '2 . . . of state transitions such that, if 
it is finite, then no admissible event is enabled in its final state Sn- A behaviour 
is a class of observation sequences starting from the same initial state Sq. 

The purpose of a system specification is to define the system behaviour, by 
specifying populations, queries, actions and activities. Informally, an activity is 
a sequence of actions performed by a group of objects to do something. The 
enabling conditions may not be sufficient to impose the desired sequence, and a 
further level of control may be needed. Activities can be modelled as constraints 
on the behaviour. For example, we can model the activity contract of purchase 
considered in Example 4 by the synchronisation constraint imposing that the 
three actions have to occur simultaneously. 

We will come back to the specification issue in Section 5. We conclude this 
section by considering space and time in an 00 system. Time is related to 
updates, while space is related to the “geometry” of the communication among 
objects. 

Navigability represents one of the space “dimensions” . We can use the clas- 
sical visibility constraints like “public” and “private”, to constrain navigability. 

A second space dimension is the observes relation: an object o observes an 
attribute o' .A of an object o' if o is interested in the updates of o' .A. The main 
reason for observing o'. A is its use in the body of a query or in the enabling 
condition of an action. However there may be many reasons for observing an 
attribute, as highlighted for example by the observer-observable pattern [9]. 

To specify dynamic aspects and to reason about them, we introduce time. 
In an observation sequence Sq Cq Si Ci S '2 . . ., each state Si {i > 0) has 
time i. We call i the global time, since observation sequences represent a global 
view of the system. 
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Besides global time, it is useful to consider local time, corresponding to the 
local view of an object or a subsystem. For example we can use Vc : Car. c@0.km 
= 0 to indicate that the odometer of a car is 0 at local time 0, i.e., when it is 
created, independently from the global time. Local time is also useful when 
considering single objects or, by a hierarchical organisation of locality, modules. 

In this paper we do not consider modules, and we introduce local time only 
for objects, by means of timed objects. A timed object with identity o and time 
t will be indicated by o@t. The time of an object increases whenever it observes 
that something is changed. 

A timed population is a set T of timed objects that does not contain pairs 
o@t, o@t' with the same object and different times. That is, each object has one 
time. The signature of a timed population T is that of its objects, where o is an 
object of T iff there is t such that o@t belongs to T. 

A timed state is a pair (T, I), where T is a timed population and I is an inter- 
pretation of its propositional symbols. Each timed state (T,I) has an associated 
(non-timed) 00 state (Prp,I), where Prp is obtained from T by forgetting time. 

An object o observes an event e if e modifies an attribute observed by o or 
the population observed by o. Timed transitions trace the observability relation: 

Definition 12. (Timed Transitions). Let (T,I) and (T',I') be two timed states. 
(T,I) e !->■ (T',I') is a timed transition ijj (Prji,I) (Prji/,l') is a state 

transition and for every o@t G T' one of the following cases holds: o@t G T and 
o does not observe e, or o@t — 1 G T and o observes e, or t = 0 and o G MO^. 

A timed observation sequence is a sequence of timed transitions, and a timed 
behaviour is a set of timed observation sequences. 

In timed observation sequences, the local time of objects implicitly traces the 
observability relation and is useful for devising independent subsystems, namely 
subsystems that can be characterised independently from their environment. 
Independence becomes a central notion when considering modularity aspects. 
We can also use a local time to trace different independent activities separately. 

4 The Meta-level and the Meta-framework 

At the meta-level, an 00 system S is represented by a reusable unit U{S), 
that we call the meta-representation of S. U{S) is an extension of the general 
meta-unit U outlined in Fig. 4. U contains a specification framework M., that 
we call the meta- framework, and an open steadfast program MP, that we call 
the meta-program. The meta-representation U{S) is obtained by adding suitable 
representation axioms and clauses, as we will outline in the next section. Here, 
we explain the general features of the meta-framework M. . 

A4 axiomatises the general assumptions on 00 systems discussed in the 
previous section, and is the basic component of the general meta-theory in Fig. 
1. It contains OBJ , to represent object identities, and 5£1T(act), to axiomatise 
the defined sort EV of events by finite sets of actions; the subframework MAT 
of 5£1T(act) is also used to represent time by natural numbers. The intended 
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unit IA\ 

MetaPramework M\ import OBJ,S£T{A-Ci:)[set{ACT) i->- ev]; 

OSORTS: ATBS, ACTS, QRYS, TPLS; 

DSORTS: OBJT, ATB, QRY, ACT; 

ODECL: del : [atb,tpls]|[qry, tpls]|[act,tpls]; 

ini : [obj,tpls]; iniT : [atb]; 

t : [nATjQRy]; toT,toF : [nAT, ACT, ATb]; 

new : [nat, ACT, OBJ, tpls]; del,obs : [n AT, ACT, OB j]; 

enb : [nat, act]; occ : [nat, Ev]; 

DDECL: . : [0BJ,ATBS[ — >■ ATB| [OBJ, QRYS[ — >■ QRY| [OBJ, ACTS] — >■ ACT; 

@ : [obj,nat] — >• OBjT; live : [nat, OBjT, tpls]; t : [nat, atb]; 

CONSTR: for o, o' : OBJ, n : NAT, a, b : ACTS,p : ATBS, e, e' : EV, A, B : ACT : 
occ(n, e) A occ{n, e') ^ e = e'; 

occ(s(n), e) A o.a £ e ^ enb(n, o.a) A . live{n, o@t)- 
occ{n, e) A o.a G e A o' .b £ e ^ ->o = o'- 
Axl: FreeAx(@ : OBjT, . : ATB, . : QRY, . : act); 

DEE: for o : OBJ; n : NAT,p : ATBS, a : ACTS, tp : TPLS : 

toNew{n,o,tp) eA 3e : ev. occ(s(n), e) A 3a G e. new{n,a,o,tp)', 

toT{n,o.p) GA 3e : EV. occ(s(n), e) A 3a G e. toT{n, a, o.p)-, 

notToF(n,o.p) ga 3e : EV. occ(s(n), e) A Va G e. -ntoF{n,a,o.p) A ~^del{n,a,o); 

obsEv{n,o) G> 3e : EV. occ(s(n), e) A (3a G e. obs{n,a,o))A 

Va G e. -idel{n, a, o); 

notObsEv{n,o) ■£>■ 3e : EV . occ(s(n), e) A Va G e. -'del{n, a,o) A -'obs{n,a, o); 

Ax2: for o : OBJ; n, t : NAT, tp : tpls : 

live{0, o@t : tp) GA ini{o, tp) At = 0; 

live{s{n),o@0 : tp) ■£>■ toNew{n,o,tp) V notObsEv{n,o) A live{n,o@0 : tp)-, 
live{s{n), o@s{t) : tp) ga obsEv{n, o) A live{n, o@t : tp) V 

notObsEv{n,o) A live{n, o@s{t) : tp)-, 

Ax3: for n : NAT,p : ATB : 
t{0,p) GA iniT{p)- 

t{s{n),p) GA toT{n,p) V notToE{n,p) A t{n,p)-, 

REPR: 

Representation axioms and specifications of 5; 

PROG MP : live{0,O@0,Templ) ini{0, Tempi). 

live{s{N), O@0, Tempi) <— toNew{N, O, Tempi). 

live{s{N), O@0, Tempi) ■£- notObsEv{s{N), O) A live{N, O@0, Tempi). 
live{s{N), 0@s{T), Tempi) <— obsEv{s{N), O) A live{N, 0@T, Tempi). 
live{s{N),0@s{T), Tempi) ■£- notObsEv{s{N),0)A 

live{N, 0@s{T), Tempi). 

t{0, P) £- iniT{P). 

t{s{N),P) £- toT(N,P). 

tlslN), P) £- notToF{N, P) A t{N, P). 

representation clauses 



Fig. 4. General meta unit. 
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models of Ai will be called meta-models. The open symbols allow us to represent 
00 systems and 00 system specifications, by the representation axioms. We 
distinguish population meta-symbols and the behavioural meta-symbols. 

The population meta-symbols are tpls, ATBS, acts, QRYS (meta-sorts for tem- 
plate identifiers and attribute, action and query signatures) and del {dcl{X,T) 
means that X is declared by the template T). They allow us to represent the 
object-level populations of an 00 system S and their signatures, by adding the 
suitable representation axioms to Ai. Since populations depend on signatures, 
the extension A4{Sg) obtained in this way will be called the signature represen- 
tation of S. We will assume that it satisfies the following regularity property: 

Definition 13. (Regularity). Let A4{Xg) be the signature representation of a 
system S, i be a meta-model of A4{Sg), and n be a natural number. Let P„ be 
the population containing the objects o : tp such that / |= 3t . live{n,o@t : tp), 
and 1„ be the set containing the ground terms o.p such that i |= t{n, o.p). We say 
that Ai{Xs) is regular if, for every n, (P„,I„) is an 00 state of S. 

The behavioural meta-symbols are introduced to represent queries, actions, 
events and observation sequences, and are interpreted within a regular signa- 
ture representation At (As). The intended correspondence with the object-level 
observation sequences, i.e., the object-level semantics, is given by the following 
definition. 

Definition 14. (Correspondence). Let Ai{Ag) be a regular representation of 
the population signatures of an 00 system S. A pre-interpretation J of A4{Ss) 
corresponds to a timed observation sequence Sq cq i— S\ ei i— >■ ... of S iff: 

1. j ^ toT{n, a, P) iff P is forced to true by the action a in S'„; 

2. J ^ toF{n, a, P) iff P is forced to false by the action a in Sn,' 

3. j ^ new{n, a, o, tp) iff o : tp is created by the action a in S„; 

4-. j\= del{n,a,o) iff o is deleted by the action a in Sn,' 

5. J ^ ini{o,tp) iff o is an object of So = (To,Io), that is, o@0 : tp G Tq; 

6. j ^ iniT{P) iff P is true in So = (To,Io), that is, P £ Iq; 

7. j \= enb{n,a) iff the enabling condition of a is true in S„; 

8. j ^ t{n, Q) iff the query Q is true in S„; 

9. j ^ obs{n, a, o) iff the updates caused by a € Cn are observed by o in Sn,' 

10. j ^ occ(s(n), e) iff the event e has just occurred at time s(n), i.e., e = e„. 

The constraints CONSTR correspond to the general assumptions on signa- 
tures, actions and events discussed in the previous section. For conciseness, we 
have indicated only the constraints on events. The constraints guarantee that 
for a regular signature representation Ai{Ss) and a pre-interpretation j that 
corresponds to an observation sequence 17, the intended meaning of the defined 
symbols is axiomatised by the definition axioms as follows. 

— Axl state that the defined sort OBjT is freely generated by @, and ATB, QRY, 
ACT by A meta-term o@t indicates an object o with local time t. The 
dot operator x.a{. . .) represents at the meta-level (by the extra-argument 
approach) the object-level renaming. 
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— DEF introduce useful abbreviations by explicit definitions. 

— Ax2 axiomatise the meta-predicate live{n,o@t,tp), with the following in- 
tended meaning: at global time n, o is a live object with local time t and 
template tp. We use the more intuitive syntax live{n,o@t : tp). 

— Ax3 axiomatise the meta-predicate t{n, p), with the following intended mean- 
ing: at global time n, the attribute p is true. 

In particular, the defined symbols live{n,o@t : tp) and t{n,p) represent the 
timed states by the projection 



i j, 

that maps each meta-model i and time n into the timed 00 state (T„,I„) such 
that o@t : tp G T„ iff i 1= live{n,o@t : tp) and o.p G I„ iff i ^ t{n,o.p). Thus, 
once we are able to represent an observation sequence 17 by a corresponding 
pre-interpretation J, the definition axioms allow us to reconstruct the states of 17 
and to reason about them at the meta level. This is what is stated by the next 
theorem and what will be used in Section 5 to represent object-level properties 
at the meta level. 

Theorem 1. Let A4{Es) be a regular representation of the population signa- 
tures of an 00 system S. Let J be a pre-interpretation of Ai{Ss) that cor- 
responds to an observation sequence O of S and be the corresponding 

j-isoinitial model. Then the sequence j, 0 Co i-G- j, 1 Cl i-A- ... such 

that J 1= occ{j, 6j) (for j = 0,1, ■ ■ ■) is a timed observation sequence that coincides 
with 17. 

Proof. Since j corresponds to 17, transitions Cj i— >■ are already defined in the 
right way. We have to show that the axioms of Ai define live{n, o@t : tp) and 
t{n, o.p) (for an attribute symbol p) in such a way that they represent 17 by the 
projections j, n. The sketch of the proof is the following. Each j^(^) j, n is a 
timed 00 state. By induction on n, we can prove that it is the state with global 
time n of 17. The basis of the induction follows from the fact that ini and iniT 
are interpreted according to Definition 14. The induction step follows from the 
fact that the open symbols toT, toF, . . . are interpreted according to Definition 
14 and from the constraints and the axioms of A4(F). 



5 Representing OO System Specifications 

The object and meta levels can be used for representing 00 system specifications 
and for reasoning about them. For lack of space, we will only outline the general 
approach and illustrate it by some representative examples. The general picture 
is illustrated in Fig. 5. S is the system specification, 0{S) is its object-level repre- 
sentation, and A4{S) its meta-level representation. 0(5) defines the operational 
semantics of 5 as a behaviour (Definition 11). M{S) is an adequate extension 
of A4. It has a model-theoretic (thus declarative) semantics, and observation 




48 



Kung-Kiu Lau and Mario Ornaghi 



S 



meta models 





' I I i? = i IJ, 

observation 

sequences 



system 

implementation 



Fig. 5. 



sequences are represented by meta-models. The dashed arrows indicate the I n- 
projections mapping a meta-model i into an observation sequence 17 = i 1|, the 
solid arrows indicate syntactic maps, and the dotted one an abstraction process, 
where observation sequences represent ideal observations of the running system 
at a given granularity. 

We distinguish behavioural and correctness specifications. 

Behavioural specifications define the system behaviour. The object-level and 
the meta-level representations have to satisfy the conditions: 

(a) M{S) includes a regular signature representation M{Bs) of S. 

(b) Let i be a finitary meta-model of At (5); then i U- =(ie/ i |0 Cq^ i|l Ci i-b- 
. . ., where i |= occ{i, Cj), is an observation sequence of 0(5). 

(c) For every observation sequence Q of 0(5), there is at least one meta-model 
i of A4(5) such that ilj. = 17. 

Correctness specifications state properties to be satisfied by the system be- 
haviour, that is, a correctness specification Sp defines a predicate P : 0(5) — >■ 
Boolean. We say that 5 is correct with respect to Sp iS P{Ci) = true, for every 
f7 G 0(5). A correctness specification Sp can be studied by representing it by 
a formula 5p f of A4 (5). We will call 5p t the meta-level representation of 5p. 
We require that: 

(d) for every meta-model i, if i ^ Sp f, then P(iU-) = true. 

If (a), (b), (c), (d) are satisfied and 5p f is a theorem of M{S), then 5 is cor- 
rect with respect to Sp. (a) and (d) must be ensured by the representation of 
signatures and specifications. Correctness can be treated in Ai{S) by proving 
5p t and the steadfastness of the meta-program. Indeed, (c) and (d) are en- 
sured by the steadfastness of the extension of MP by the representation clauses. 
Furthermore, MP gives rise to a reflective environment, where we can perform 
meta-level computations. 

We conclude this section with some examples that illustrate the approach 
outlined above. 

Example 5. Representing Signatures, Queries and Actions. In this ex- 
ample we consider languages where the object-level representation of a speci- 
fication 5 can be formalised as a quadruple 0(S) = {T>,P, Q,A), where: V is 





Correct 00 Systems in Computational Logic 



49 



the data type of S, V is the set of its populations, and Q and A are semantic 
maps that associate every population P with the queries Q(P) and the actions 
^(P) of P. The specified behaviour 0 {S) contains the observation sequences 
(Pi, Ii)ei !->■ (P2, 12)62 such that P^ are populations of P and the actions 

and queries of Pi are given by the maps A and Q. We will call this behaviour 
the free behaviour of S. 

We show a possible Prolog-like specification language of this kind, by means 
of the following example, where queries and actions are added to the template 
classes Car and Person of Example 2. 

Class Car : 

NAVATB : .owner :[]—>■ OBJ; 

ATB : .km :[]—>■ Integer; 

QRY : self.sameOwner(c) self .owner is{p) A Person{p) A p.owns{c); 

ACT : toT{self .sold{pi,p2), self .owner is{p2)) ^ 

Class Person : 

NAVATB : .owns : [obj]; 

ACT : toT{self.buys{c,p),self.owns{c)) •<— ; 

toF{self .sells{c,p) , self .owns{c)) -fr- self .owns{c); 

A query clause is defined in a template T and its atoms may be of the form 
self .A, where A is a query or an attribute of T, or of the form d.A, where 
the message destination d {p in the Example) is different from self, must be 
bounded by a template predicate T'{d) {Personfp) in the Example) and A must 
be declared in T' . An action clause has a similar syntax, but now the head is 
an update atom and the enabling condition must be the same in all the clauses 
defining the same action. 

Now we build the object-level representation 0 {S). The data type and pop- 
ulations are defined as in Example 2. We associate each population P with the 
actions A(P) and the queries Q(P) of P, as follows. 

Q(P) is obtained by grounding each query clause Q by replacing self by the 
identities o such that o : T G P, and the (possible) message destinations d by 
the identities o' such that o' : T' G P. A(P) is obtained by the same grounding 
process. For instance, the query given in Example 3 is the object level semantics 
of the query clause for sameOwner in the population there considered, and the 
actions in Example 4 are the object-level semantics of the above action clauses. 

To build the meta-level representation Ai{S), firstly we have to extend Ai 
into a regular signature representation M{Ss)- For this, we include the data 
type XMTSQEP and we close the population signature by the declarations and 
axioms^: 

Car, Person : [] — >■ tpls kmis : [Integer] -A ATBS 
owner is : [Obj] -A ATBS owns : [Obj] -A ATBS 

® The syntax fcmis(n) has not been considered in Section 4 for conciseness. It can be 

treated by introducing in M suitable meta-symbols and constraints. 
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FreeAx{Car, Person : tpls, km is, owner is, owns : ATBS, nil : QRYS, nil : acts) 
dcl{a,Car) ^ {3n. a = kmis{n)) V {3p. a = owner is{p)) 
dcl{a. Person) o 3c. a = owns{c)) 

We can show that this way of closing the population signature is general and 
gives rise to regular representations, considering only templates. A suitable meta- 
theory can be introduced in to treat classes and polymorphism. 

To complete the meta- level representation A4(S), we add the representation 
axioms of specifications of queries and actions, according to Example 7. 

Finally, to complete the meta-program, we translate the query and action 
clauses of the specification into meta-clauses defining the open meta-predicates 

t, toT, toF, The translation introduces the global time n, replaces self by a 

fresh variable x, and x is bounded in the body by live{n,x@t : T), where T is 
the template of self. Similarly, the template predicate T'{d) for a destination d 
is translated by live{n,d@t' : T'). The resulting meta-clauses are added to the 
meta-program MP. For lack of space we omit the details. To give an example, 
the meta-clauses representing the query and action clauses considered before are: 

t{n,x.sameOwner{c)) Y- live{n,x@t : Car) A t{n,x. owner is{p)) 

A live{n, p@t : Person) A t{n.p.owns{c)); 
toT{n,x.sold{pi,p 2 ),x.owneris{p 2 )) Y- live{n,x@t : Car); 
toT{n,x.buys{c,p),self.owns{c)) ^ live{n,p@t : Person); 
toF{n,x.sells{c,p),self.owns{c)) Y- live{n,p@t : Person) A t{n,x.owns{c)). 

Example 6. Activities. An activity specification is a behavioural specification. 
It is expressed as a constraint on the free behaviour of a system specification. 
Here we show the example of a possible syntax for expressing synchronisation 
constraints. The example shows a collaboration of three objects implementing a 
contract of purchase. 

Collaboration pi,p2 : Person; c : Car : 

ACTIVITY contractO f Purchase : 
sync{c.sold{pi,p 2 ), [pi.sells{c,p2),P2-buys{c,pi)]) 
sync{pi.selb{c,p 2 ), [c.sold{pi,p2),P2-bu]p{c,pi)]) 
sync{p2.buys{c,pi), [c.sold{pi,p2),Pi.selb{c,p2)]) 

The statement sync(a, 1) means that action A synchronises the actions in 1. 
The object-level representation of synchronisation clauses is given in the way 
illustrated for queries and actions. Their semantics is the constraint imposing 
that an event containing an action A synchronising B must also contain B. This 
constraint is expressed at the meta level by the meta-axiom: 

occ(e, n) A a G e A sync{n, a,s)AbGs^b€e 

and we have to add the meta-level representation of the synchronisation clauses. 

Example 7. Correctness Specifications and Invariants. There are various 
kinds of correctness specifications. To deal with open correctness (steadfastness) 
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queries and actions must have specifications. Actions are specified by a combined 
use of pre/post-conditions and invariants. Query specifications can be treated as 
in [14]. 

Each kind of specification has a specific meta-level representation. We con- 
sider only invariants, for lack of space. Invariants represent properties that must 
hold in every state, or at least in chosen states, determined for example by the 
local time or by spy points. An example is the invariant 

Context Car 

INV zeroKm : self@0.km = 0 

Like in OCL [22], a constraint is given in the context of a template in a speci- 
fication. Here the informal correctness property P (see condition (d)) expressed 
by the invariant is: “for every state S and object c : Car, c.kmis{0) holds in S 
if the local time of c is 0” . Instead of giving a separate object-level semantics, 
we can give directly a meta-level representation S f and assume condition (d) 
as defining the object-level semantics. In our example zeroKm f is 

\/n,c. live{n,c@0: Car) — >■ t(n, c.fcmis(O)) 

We can see that the above formula is true in a meta-model i iff, in the observation 
sequence 17 = ilj., c.fcm is(0) is true in every state with a timed population 
containing g@0 : Car. This formalises the informal predicate P. 

Example 8. General-purpose Specifications. In general, a separate specifica- 
tion formalism is useful to express specifications in a more compact and natural 
way, and it is convenient to choose different formalisms for different purposes. 
There are cases where it is convenient to directly use the met a level as a specifica- 
tion formalism. This choice may be adequate, for instance, to express constraints 
that are not domain specific. For example, fairness is expressed by the constraint 

Vn : NAT, a : ACT. enb{n,a)^3m. m > n /\ occ{m,a) 

This constraint does not depend on the application domain, but it may be seen 
as a constraint for the implementations of the programming language. If we 
assume it, then we require that implementations apply a fair scheduling. 



6 Conclusion 

We have introduced a three-level formalisation of 00 systems, with an object 
level, a meta level and many possible specification levels, linked by the maps 
illustrated in Fig. 5. In this context, the specification and meta levels can both 
be used to write down specifications, while the object-level semantics relates 
specifications to the corresponding system configurations. 

Our approach is very similar, in spirit, to the multi-level approach of UML 
[19]. In UML, the official specification language is OCL [22]. Various efforts have 
been made to give a formal semantics to OCL and some Java implementations 
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have been developed [18]. Although we start from a different background, one 
that is closer to formalising UML by ADTs [3,8], our multi-level approach has 
many similarities to the approaches developed in the UML and OCL community. 
In particular, we have in common the static diagrams, namely class and object 
diagrams, including invariants, and our behavioural specifications are similar, 
in a broad sense, to the UML behavioural diagrams. However, our approach is 
logically based, and is in this regard close to approaches for formalising UML 
and OCL. A first formalisation of OCL in Isabelle HOL has been proposed in [4]. 
The approach of [5] is based on the specification language Z. There is a working 
group on precise UML [21]. 

Concerning the dynamic aspects, at the object level our model is similar to 
the approaches based on temporal logic [8] . Indeed, behaviours can be considered 
as a particular kind of Kripke Transition Systems [16], where each Kripke world 
has an associated population. Populations allow us to model open systems, in 
a way similar to [1]. Instead of adding temporal operators to the object level, 
we have preferred to model time at the meta-level, because this allows us to 
extend our previous work on open specification frameworks and steadfast open 
programs [15]. Moreover, temporal logic operators could be introduced at the 
specification level. That is, our approach is not alternative, but complementary 
to temporal logic approaches. 

In this paper, the main effort has been to extend our previous three-level for- 
malisation of static 00 systems by introducing time. The proposed formalisation 
is the basis for long-term work, involving many related aspects: 

(a) Classes, types and polymorphism. With a slight extension of the meta-lan- 
guage and of the related constraints, we can define classes and types, together 
with inheritance and overriding polymorphism. 

(b) Implementing the object and the meta-levels. It is possible to build a Prolog 
interpreter for the object level and the meta-level, by introducing a syntax 
for representing classes, attributes and methods. We are looking for a tool 
that is useful for understanding specifications (e.g., by animating them), 
rather than a tool for implementing 00 systems. 

(c) Specification languages. In Section 5, we have shown some examples of spec- 
ification formalisms, at an intermediate level between the meta- and the 
object level. The idea is that different aspects are treated in a more natural 
way by different formalisms (in this, we are in line with the general ideas un- 
derlying the UML approach), and that the meta-framework is the unifying 
framework. 

(d) Correctness. Correctness can be defined in terms of steadfastness at the 
meta level, and can be proved using the results of [15]. We have not yet 
studied specific proof strategies, but we can reasonably expect that different 
specification languages will underly different proof methods. 

(e) Modules. We have only some ideas, to be developed further. Essentially, the 
idea is to formalise modules by enriching the structure of local time. 

Our next steps will be (a) and (b), but really all the previous points have to be 
developed if we want to reach our final goal, which is to model OOD frameworks 




Correct 00 Systems in Computational Logic 



53 



[12] by open reusable units. Clearly this paper represents just a step in that 
direction. 
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Physics-based animation programs are useful in a variety of contexts, including 
science, engineering, education and entertainment. For example, in science, they 
are used to investigate the behavior of dynamical systems. In engineering, they 
are used to help design vehicles, machinery and other mechanical devices. In 
education, they are used to teach basic principles of physics. In entertainment, 
they are used in games involving cars, planes, spaceships and other moving 
objects. Such programs are usually constructed by hand, in conventional pro- 
gramming languages, such as C-|— 1-, possibly augmented with a physics-based 
animation toolkit. Unfortunately, manual construction of physics-based anima- 
tion programs is expensive, time-consuming and highly prone to error. 

A considerable portion of the difficulty results from the need to track and 
manage instantaneous changes in the states of objects and the equations and 
constraints that govern their behavior. For example, when one rigid body collides 
with another, the objects’ states of motion may change instantaneously. If the 
contact persists for a period of time, the governing equations of motion and 
constraints may change as well. Similar instantaneous changes occur when an 
autonomous agent switches from one control mode to another. For example, 
when the driver of a car depresses or releases the accelerator or brake, the car’s 
acceleration may change instantaneously. 

In previous work, the author and his students developed a system for spec- 
ification and synthesis of numerical simulation programs for physics-based ani- 
mation applications [2] . The system allows a developer to specify the geometry, 
shading, lighting and camera angles of a scene in 3D Studio Max(R) and specify 
the dynamics of the scene in Mathematica(R) . A Mathematica program pro- 
cesses these specifications and generates a numerical C-|— I- program that inter- 
leaves simulation and rendering to generate a real time animation of the specified 
scene. This work drew upon the field of analytical dynamics, in which motion 
is governed by differential equations involving forces and constraints, for mod- 
eling physical systems. The equations were assumed to remain fixed over time, 
resulting in continuous and smooth motion, ignoring the complexities described 
above. 

We have recently extended the system to hybrid automata [3]. A hybrid au- 
tomaton includes both discrete and continuous dynamical variables. The discrete 
variables define the automaton’s modes of behavior. The continuous variables are 
governed by mode-dependent differential equations. Hybrid automata are suited 
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to modeling physical systems with instantaneous changes in forces, constraints 
and equations. They are also suited to modeling some types of autonomous be- 
havior by agents operating in a physics-governed environment. 

We have defined a family of parameterized specification schemata. Each 
scheme describes a pattern of behavior as a hybrid automaton passes through a 
sequence of modes. A developer can specify a program by selecting one or more 
schemata and supplying application-specific instantiation parameters for each 
of them. Each scheme has a declarative interpretation, and can be combined 
with other schemata in an order-independent fashion. We have associated each 
scheme with a parameterized sentence in a logic of hybrid systems. The sentence 
serves to document the semantics of the specification scheme. We have also de- 
veloped sets of rewrite rules that implement each of the specification schemata 
in a general physics-based animation architecture. 

We have tested the system on over a dozen examples. In one example, a ball 
rolls down a series of steps, repeatedly making transitions between a rolling mode 
and a bouncing mode. In another example, a robot drives around a track and 
repeatedly picks up and puts down a ball. In so doing, the robot makes tran- 
sitions between driving, reaching, carrying and placing modes. In yet another 
example, two spaceships orbiting a planet are shooting torpedoes at each other. 
The specifications assert that the torpedoes are launched with initial velocities 
that cause them to fly along ballistic trajectories to hit their targets. The sys- 
tem automatically synthesizes a numerical shooting method to implement the 
specification. Experimental results on these and other examples are described in 
a full length version of this paper[l]. 

The long-term goal of this research is to develop a specification language and 
synthesis system that is general enough to handle a wide variety of animation 
programs, yet restricted enough to permit programs to be synthesized automat- 
ically. We are taking an incremental approach in working toward this goal. We 
intend to expand, generalize and unify the specification schemata and synthesis 
techniques over time. We expect the process will lead eventually to a logic-based 
specification language and synthesis system with a combination of expressive- 
ness and automation that makes it useful for developing animation programs in 
real-life applications. 
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1 Introduction 

Program generation and transformation systems work on two language levels, 
the object-level (i.e., the language of the manipulated programs), and the meta- 
level (i.e., the implementation language of the system itself). The meta-level 
representations of object-level program fragments are usually built in an essen- 
tially syntax-free fashion using the operations provided by the meta-language. 
However, syntax matters and a large conceptual distance between the two lan- 
guages makes it difficult to maintain and extend such systems. Here we describe 
how an existing Prolog-based system can gradually be retrofitted with concrete 
object-level syntax using the approach outlined in [5], thus shrinking this dis- 
tance. 

2 AutoBayes 

AutoBayes [1] is a fully automatic program synthesis system for statistical 
data analysis problems like the analysis of planetary nebulae images taken by 
the Hubble space telescope [2]. Its implementation currently comprises about 
80,000 lines of SWI-Prolog code. AutoBayes derives code from statistical mod- 
els of the data using a schema-based approach. Schemas consist of parameterized 
code fragments (i.e., templates) and constraints. The code fragments are writ- 
ten in a sanitized variant of C (e.g., no pointers) that also contains a number 
of domain-specific extensions (e.g., matrix expressions). The fragments repre- 
sent the solution methods of the domain, for example statistical algorithms like 
/c-means clustering or numeric optimization algorithms like the Nelder-Mead 
simplex method. The constraints determine whether a schema is applicable and 
how the parameters - and thus the code - can be instantiated, either directly by 
the schema or by AutoBayes calling itself recursively with a modified model. 
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3 Program Generation in Prolog 

In the current AutoBayes- version, schemas are implemented as simple Prolog- 
clauses that return a term representing the appropriately instantiated algo- 
rithms. The schemas assemble the fragments from many small code pieces that 
are bound to Prolog-variables acting as met a- variables; otherwise, the abstract 
syntax would become unreadable. The schemas are also sprinkled with many calls 
to small meta-programming predicates that for example generate fresh object- 
level variables or build other constructs of the object language. A particular 
nuisance is the repeated use of Prolog’s built-in = . . -operator to construct com- 
pound object-level terms with variables as head symbols, which is necessary for 
second-order term formation. This general style makes it hard to follow and un- 
derstand the overall structure of the algorithm and thus difficult for a domain 
expert to modify and write schemas. 

4 Migration to Concrete Syntax 

Schema migration involves three easy steps. First, terms representing program 
fragments in abstract syntax are replaced by the equivalent fragments in concrete 
syntax; these fragments are marked by a quotation operator. Then, calls to meta- 
programming predicates are replaced by the appropriate object-level constructs. 
For example, the explicit generation of fresh object variables is expressed in 
the object code by tagging the corresponding meta-variable with a special anti- 
quotation operator. Finally, the schema is refactored by inlining the program 
fragments. 

The necessary extension of Prolog with concrete syntax relies on the combi- 
nation of three techniques, (i) The syntax definition formalism SDF2 [4] is used 
to specify the syntax of both languages as well as the embedding (i.e., quotation 
mechanism and met a- variables), (ii) The transformation language Stratego [6] 
is used to map syntax trees over this combined language back into pure Pro- 
log programs. This eliminates the concrete syntax, (in) Stratego is also used 
to adapt the resulting schemas into the exact form required to interface them 
with the remaining AuTOBAYES-system. For example, second-order term forma- 
tions and fresh variable anti-quotations are hoisted out of the resulting abstract 
syntax terms and turned back into the original constructors and fresh variable 
generators provided by the meta-programming kernel. 

5 Conclusions 

We applied the generalized approach to meta-programming with concrete object- 
syntax to some of the schemas in AutoBayes. In these cases, the introduction of 
concrete syntax reduces the schema size by about 30% and improves the readabil- 
ity and locality of the schemas. In particular, abstracting out second-order term 
formation and fresh- variable generation allows the formulation of larger contin- 
uous fragments. Moreover, meta-programming with concrete syntax is cheap: 
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using Stratego and SDF2, the overall effort to develop all supporting tools was 
less than three weeks, Once the tools were in place, the migration of a schema 
was a matter of a few hours. Finally, the experiment has also demonstrated that 
it is possible to introduce concrete syntax support gradually, without forcing a 
disruptive migration of the entire system to the extended meta-language. The 
seamless integration with the “legacy” meta-programming kernel is achieved 
with a few additional transformations, which can be implemented quickly in 
Stratego. 
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Abstract. For many intractable optimization problems efficient approx- 
imation algorithms have been developed that return near-optimal solu- 
tions. We show how such algorithms and worst-case bounds for the qual- 
ity of their results can be developed and verified as structured programs. 
The proposed method has two key steps. First, auxiliary variables are 
introduced that allow a formal analysis of the worst-case behavior. In a 
second step these variables are eliminated from the program and existen- 
tial quantifiers are introduced in assertions. We show that the elimination 
procedure preserves validity of proofs and illustrate the approach by two 
examples. 



1 Introduction 

Algorithm design and formal program development and verification are two well 
established domains in computer science and applied mathematics. Formerly 
they mostly have been coexisting. However in recent years many computer sci- 
entists noticed that the design and verification of efficient algorithms which are 
not only correct “in principle” but in all details can benefit from techniques of 
formal program development and verification. Therefore, there is an increasing 
cooperation between the two fields. 

In this paper techniques of formal program development and verification are 
applied to approximation algorithms. Such algorithms (see [11] for an overview) 
have been developed because a great variety of important optimization prob- 
lems cannot be solved efficiently (unless P = NP). Approximation algorithms 
are usually very fast but return only near-optimal solutions. Hence, besides fea- 
sibility of their results, estimates for the closeness to the optimal solutions are of 
interest. We show how approximation algorithms and, in particular, their worst- 
case bounds can formally be derived and verified as structured programs using 
the well-known assertion method pioneered by Floyd and Hoare [7, 10,5, 1]. 
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The proposed method for proving worst-case bounds has two key steps. In 
the first step, auxiliary variables are added to the program. They are used to 
collect information that is referred to in the informal proofs but is not present in 
the algorithm itself. The worst-case behaviour can then be analysed formally by 
strengthening the assertions used in the feasibility proof. In the second step, the 
auxiliary variables are removed from the program and existential quantifiers are 
introduced in assertions. This avoids the inefficient calculation of auxiliary vari- 
ables at run-time. It also allows to use non-constructive or expensive operations 
in assignments to auxiliary variables. We show that this elimination procedure 
preserves validity of partial correctness proofs. 

The paper is organized as follows: Section 2 illustrates that auxiliary variables 
are useful for a formal verification of worst-case behaviour. For this purpose, 
we recall a well-known approximation algorithm for the minimum vertex cover 
problem and its proof in the usual semi-formal mathematical way. Afterwards, 
we show how this proof can be formalized. Proof outlines, which are decisive 
for our reasoning, are considered in Section 3 and three simple conditions for 
their validity are presented. In Section 4 we show how auxiliary variables can be 
eliminated from proof outlines and prove that the resulting proof outline shows 
the same partial correctness property as the original proof outline. Section 5 
applies our method to a second example, an approximation algorithm for the 
problem of computing an independent set of maximum size. We also discuss 
some variants of this algorithm. We conclude in Section 6 with some further 
applications and ideas for future research. 

2 An Illustrative Example 

Let g = (y, E) be an undirected and loop-free graph with finite (and non-empty) 
set V of vertices and set E of edges, where each edge is a set {x, y} with x,y gV 
and X =/= y. A vertex cover of (/ is a subset C of V such that every edge in g is 
incident to some vertex in C, i.e., e fl (7 yf 0 for all e G E. To compute a vertex 
cover of minimum size is an AP-hard problem; see [3]. There is a simple greedy 
approximation algorithm for that problem attributed to Gavril and Yannakakis 
in [3]. Expressed as a while-program it reads as given below, where we assume 
that the non-deterministic assignment e :G F assigns an arbitrary element of 
F yf 0 to e and the call inc{e) yields the set {/ G F | e fl / y^ 0} of all edges 
incident to edge e: 

C:= 0;F:=F; 

while F y^ 0 do \ 

e :G F; 

C := C U e; F := F \ inc{e) od . 

In [3] it is also shown that this program always returns a vertex cover C of g 
whose size \C\ is guaranteed to be no greater than twice the minimum size Copt 
of a vertex cover of g. The idea underlying this proof is to consider the set M 
of all edges that were picked by the statement e :G F and to show that M is a 
matching of g with \C\ < 2* |M|. (A set of edges is a matching if no two different 
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edges are incident.) The estimation ICj < 2*Copt then follows from the fact that 
a vertex cover C* of g of minimum size must include at least one vertex of any 
edge of M, i.e., \M\ <1(7*1 = Copt- 

As is prevalent in the literature on algorithmics, the correctness proof of 
Gavril and Yannakakis’ algorithm in [3] is done in a “free-style” mathematical 
way without formal problem specification and program verification. Nevertheless 
it can also be formalized in the assertion approach if the program (VCi) is refined 
by a pre-condition, a loop invariant, and a post-condition as follows: 

{ true } 

C := 0; F := Tl; M := 0; 

{ inv{C, F, M) } 

while F yf 0 do (VC 2 ) 

e :G F; 

(7 := (7 U e; F := F \ inc{e);M := M U {e} od 
{ post{C) } . 

The loop invariant inv{C, F, M) is defined as the conjunction of 



C vertex cover of gp = (V,E\F), (1) 

M matching of g = {V, E ) , (2) 

|(7|<2*|M|, (3) 

VeGM,/GF:en/ = 0, (4) 

and the post-condition post{C) as the conjunction of 

C vertex cover of g = (F, F) , (5) 

|C|<2*Copf (6) 



The annotated program (VC 2 ) terminates regularly since the non-deterministic 
assignment e :G F is defined because of the condition F yf 0 of the while-loop 
and, due to e G inc(e), the value of F is strictly decreased in every run through 
the while-loop. To show partial correctness of (VC 2 ) wrt. the pre-condition true 
and the post-condition post{C), three proof obligations have to be discharged 
(see Section 3 or [6,9] for details). First of all, the initialization must establish 
the loop invariant if the pre-condition holds, i.e., 

true => otv(0,F, 0). 

Secondly, each execution of the loop’s body must maintain the loop invariant, 
i.e., the implication 

F y^ 0 A mw((7, F, M) znw((7 U e, F \ znc(e), M U {e}) 

must be shown for all (7, F, and M and for any e in F. The proofs of both 
implications are easy exercises and, therefore, left out. Note, however, that in 
the second case assertion (4) is necessary to obtain the matching property of 
M U {e} from e G F and the matching property of M . The third and final task 
is to show that upon termination of the loop the post-condition follows from the 
loop’s exit condition and the loop invariant, which leads to 
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F = 0 A inv{C, F, M) post{C) 

for any C, F and M as last proof obligation. Here (5) follows from (1) and F = 0 
and (6) is a consequence of (2) and (3), as already shown. 

3 Proof Outlines 

Proof methods for correctness of programs have been the topic of intense research 
for more than three decades (see [5] for an overview). Floyd’s method [7] of 
inductive assertions and Hoare logic [10] are particularly well known. In this 
paper we use proof outlines for proof presentation which combine the strength 
of both methods. They allow a proof presentation on the level of structured 
programs but lead to a more compact proof representation as full proof trees. A 
proof outline is a program annotated with assertions as the example (VC2) in 
Section 2. 

An assertion is a predicate on the values of the variables used in a program. 
In practice, assertions are given by predicate-logic formulas. Suppose we have 
two assertions pre and post. Then, program tt is called partially correct with re- 
spect to pre-condition pre and post-condition post if any terminating execution 
of 7T from an initial state that satisfies pre ends in a state that satisfies post; if, 
in addition tt terminates from any state in pre, it is called totally correct with 
respect to pre and post. While we are ultimately interested in total correctness, 
it is in most cases easier in formal program development and verification to first 
concentrate on partial correctness and prove termination separately afterwards. 
Because there is nothing special about termination proofs of approximation al- 
gorithms, we focus on partial correctness reasoning in this paper. 

A program element is a Boolean expression (condition) or an atomic state- 
ment. We will discuss the following types of atomic statements in this paper: 
the “do-nothing” statement skip, (deterministic) assignments x := t, and non- 
deterministic assignments x :G S. For simplicity, we assume that t and S are 
total expressions. The exposition can straightforwardly be extended to other 
kinds of atomic statements. 

Now, let p and q be two assertions in a proof outline. Then a segment from p 
to (7 is a sequence of program elements that may be traversed successively in an 
execution of the underlying program on the way from p to q; a segment is not 
allowed to extend over an assertion. We refrain from a more formal definition 
but provide an illustrative example. Consider the following simple generic proof 
outline, where Si, S 2 , S 3 , and S 4 are atomic statements, 6 is a condition, and 
pre, inv, and post are assertions: 



{ pre } 

Si;S2; 

{ inv } 
while b do 
F3;A4 od 
{ post } . 
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In it, we have the three segments { 81 , 82 ) from pre to inv, (6, 5'3,S'4) from inv 
to inv, and {-ib) from inv to post. 

As demonstrated in Section 2, each segment in a proof outline gives rise to 
a proof obligation: it must be partially correct with respect to the surrounding 
assertions. This proof obligations is best captured in terms of the weakest liberal 
pre-condition of the segment, which is inductively defined by 

wlp(£,g) :<l=^ q, 
wlp(e-s,g) wlp(e, wlp(s, q)) . 



Here £ is the empty sequence {empty segment) and e-s is the concatenation of 
the program element e and the segment s. This definition refers to the weakest 
liberal pre-condition of program elements, which is given by 



wlp(6,g) 
wlp(skip, q) 
w\p{x:=e, q) 
wlp(a;:G 8 , q) 




b^q, 

5^0A(VsGS':g[s/x]). 



It is understood that s is a fresh variable in the clause for x :G 8 , i.e. a variable 
q is independent of, and q[s/x\ is obtained by substituting s for x in q. 

Note that the conjunct S' yf 0 in the clause for x :£ 8 puts the obligation 
on the algorithm designer to prove that 8 is non-empty. Omitting this conjunct 
results in an alternative definition in which wlp(a; :G 8 ,q) holds trivially for 
all states, in which 8 evaluates to the empty set. One could argue that this 
alternative definition would be in accordance with the philosophy of partial 
correctness: to choose a value from an empty set should result in a run-time 
error and, like divergent paths, execution paths leading to run-time errors could 
be ignored in partial correctness. However, without the conjunct S yf 0 we 
cannot allow non-deterministic assignments to auxiliary variables as otherwise 
the elimination procedure described in Section 4 would become unsound. Here 
is a minimal example for the problem: without the conjunct S' yf 0, the proof 
outline {true} a :G 0 {false} is valid in the sense defined below. Step (i) of the 
elimination procedure of Section 4, however, results in {true} skip {false} which 
is certainly wrong. 

Now, a proof outline is valid for assertions pre and post if it satisfies the 
following three conditions: 

(a) Assertion pre is placed at the beginning and assertion post at the end of the 
proof outline. 

(b) Any loop in the underlying program is broken by an assertion; typically this 
is achieved by placing a loop invariant right in front of every loop. 

(c) For every segment s from an assertion p to another assertion q in the proof 
outline, p implies wlp(s,( 7 ). 

Intuitively, the second condition guarantees that a proof outline induces only 
a finite number of segments and the last condition says that all segments are 
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partially correct wrt. the surrounding assertions. As every execution of the pro- 
gram is composed of executions of segments, a valid proof outline proves partial 
correctness of the underlying program tt wrt. pre and post. 

4 Auxiliary Variables and Their Elimination 

The example in Section 2 illustrates that the enrichment of programs and proof 
outlines by auxiliary variables often allows a clearer statement of the underlying 
argument in a formal verification. However if the auxiliary variables are left 
in the executed version of the program they may lead to inefficiencies caused 
by additional computations, which in certain cases even forbids the use of the 
modified programs in practice. 

In order to overcome this disadvantage, we show in this section that aux- 
iliary variables can always be eliminated from proof outlines without affecting 
their validity. From a theoretical point of view, this result proves that auxiliary 
variables are unnecessary in order to perform a correctness proof. Nevertheless, 
we recommend their practical use because of the above reason. Note that our re- 
sult even allows the use of pre-algorithmic constructs (like set comprehension or 
quantification) in assignments to auxiliary variables. This often simplifies formal 
reasoning considerably. 

In view of our applications, a finite set of variables A is called a set of auxiliary 
variables in a program tt if variables a € A are used only in assignments of the 
form X := torx'.GS where x € A. That is: auxiliary variables must not be used in 
assignments to non-auxiliary variables and in guards of loops or conditionals^ . 
Therefore, they can neither influence the control flow nor the values held by 
non-auxiliary variables Auxiliary variables may be used freely in the assertions 
of a proof outline. In order to ensure that the specification proved by a proof 
outline is independent of auxiliary variables, we require, however, that auxiliary 
variables do not appear freely in the pre- and the post-condition. In the proof 
outline (VC 2 ) in Section 2, for instance, M is an auxiliary variable. 

In order to eliminate the auxiliary variables a € A from tt, we perform the 
following simple step; the resulting program is called if in the following. 

(i) Remove any assignment of the form a := t or a:G S with a G A from tt. 

We can think of this step as a replacement of all these assignments in tt by the 
neutral statement skip. Of course, a valid proof outline for tt will in general 
no longer be valid if tt is replaced by the modified program jt, as the assertions 
may use auxiliary variables in an essential way. As we will prove in a moment, 
however, we can regain a valid proof outline for jt by the following second step: 

(ii) Replace in addition any assertion p in the old proof outline in which 
auxiliary variables occur freely by the assertion (3ai, . . . ,ak ■ p), where 
oi , . . . , Ofe G A are the auxiliary variables occurring free in p. 

^ Some authors, e.g., [13], use the notion “auxiliary variables” for variables whose 
appearance is restricted to assertions and whose values may not be changed by 
programs. Usually, in the literature such variables are called logical variables. 
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Note that this transformation of the proof outline leaves both pre- and post- 
condition unchanged, as they do not contain free occurrences of auxiliary vari- 
ables. Hence, the modified proof outline proves, if indeed valid, the same partial 
correctness property as the original one, but for the modified program tt. 

If we apply (i) and (ii) to the valid proof outline (VC 2 ) of Section 2 we get the 
following valid proof outline (VC 3 ) showing the partial correctness of the original 
program (VCi) wrt. the pre-condition true and the post-condition post{C): 

{ true } 

C:= %-F:=E- 
{ 3 M : inv{C,F,M) } 

while F yf 0 do (VC 3 ) 

e :G F; 

C := C U e; F := F \ inc{e) od 
{ post{C) }. 

Let a be a list of variables that contains each variable of A exactly once. We 
now show that the application of steps (i) and (ii) to a valid proof outline leads 
always again to a valid proof outline. As the first two conditions (a) and (b) of 
Section 3 for validity of proof outlines are not affected by the transformation 
via (i) and (ii), we only have to show that the third condition (c) remains true. 
Without loss of generality, we can assume that step (ii) replaces all assertions p 
in the proof outline by (3 a : p). This assumption which smoothes the proof is 
justified by the fact that existential quantification over variables a predicate q is 
independent of results in an equivalent predicate. 

As a preparation for the correctness proof, we show an interesting relationship 
between a program element e in the original program and the program element 
e which replaces it in the modified program when step (i) is applied: 

Lemma 4.1. Let q be an assertion. Then 

(3 a : wlp(e,< 7 )) =A wlp(e, (3 a : g)) . 

Proof. The assertions (3 a : wlp(e,< 7 )) and wlp(e, (3 a : q)) are even equivalent 
if the program element e is skip, a deterministic assignment a; := t to a non- 
auxiliary variable x, or a guard b. For e being skip this is obvious: both assertions 
reduce to (3 a : g). For deterministic assignments equivalence is proved by 

(3 a : w\p{x:=t, q)) 

(3a: q[t/x\) definition wip 

{3a-.q)[t/x\ predicate logic 

wlp(a;:=t, (3 a : q)) definition wIp. 

The second equivalence exploits that a: is a non-auxiliary variable and that t 
does not depend on auxiliary variables. 
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The case of guards is shown by 



(3a : wlp( 6 ,< 7 )) 
(3 a : 6 — >■ g) 

6 — >■ (3 a : g) 
wlp(&, (3 a : q)) 



definition wip 
predicate logic 
definition wIp. 



Note that the second equivalence depends on b being independent of auxiliary 
variables and the fact that the variables of a have a non-empty type, a standard 
assumption for program variables. 

In the case of a non-deterministic assignment x:GS to a non-auxiliary vari- 
able X we calculate as follows, where the second step exploits that S is indepen- 
dent of all the variables in a because a consists of auxiliary variables and the 
third step that for the fresh variable s the property s (ji A can be assumed: 



(3 a : wlp(x:G S, q)) 

(Ba : S 0 A (V s G S : q[s/x\)) 
S 0 A {y s G S : (3 a: g[s/x])) 
S ^ 0 A {y s G S : (3 a: q)[s/x]) 
wlp(a;:G S', (3 a : q)) . 



definition wip 
predicate logic 
since x,s ^ A 
definition wip. 



For deterministic assignments to an auxiliary variable a G A the proof looks as 
follows, where in the fourth step of the derivation s is replaced by a and the two 
quantifiers are combined. 



(3 a : wlp(a := t, q)) 

(3 a : q[t/a\) 

(3 a : (3s : s = t A g[s/a])) 
(3 a : (3s : g[s/a])) 

(3 a : g) 

wlp(skip, (3 a : g)) 



definition wip 
one-point rule 
weakening 
see above 
definition wip. 



Finally, for a non-deterministic assignment a :G S to an auxiliary variable we 
calculate as follows, where in the second step the conjunct S yf 0 ensures that the 
range of the universal quantification is non-empty such that it can be weakened 
to an existential quantification: 



(3 a : wlp(a:G S, g)) 
(3a:S'yf0A (VsGS': g[s/a])) 
(3a:S'yf0A {3s G S : g[s/a])) 
(3 a : (3 s : g[s/a])) 



definition wip 
see above 
weakening. 



The last formula is equivalent to wlp(skip, (3a : g)) as we have seen in the proof 
for deterministic assignments to auxiliary variables. □ 



A simple inductive argument shows that the implication in Lemma 4.1 transfers 
from program elements to segments: 




Formal Development and Verification of Approximation Algorithms 



67 



Lemma 4.2. Suppose s is a segment in the original proof outline, s is the cor- 
responding segment in the modified proof outline, and q is an assertion. Then 

{3d : M\i\p{s,q)) wlp(s, (3 d : q)) . 



Proof. The induction base of s being empty is trivial: since s is empty, too, both 
sides of the implication reduce to (3d : g). 

For the induction step of s being of the form e-r we get the derivation 




(3 a : wlp(e-r, q)) 

(3d : wlp(e,wlp(r, g))) 
wlp(e, (3d : wlp(r, q))) 
wlp(e,wlp(f, (3d : g))) 
wlp(e-f, (3 d : g)) 



definition wip for segments 
Lemma 4.1 

induction hypothesis, monotonicity 
definition wIp for segments 



which concludes the proof since the concatenation e-r is modified to e-r. □ 

After these preparations, it is now easy to show correctness of the elimination 
procedure. 

Theorem 4.1. The application of steps (i) and (ii) to a valid proof outline leads 
again to a valid proof outline. 

Proof. As conditions (a) and (b) of Section 3 for validity of proof outlines are 
not affected by the transformation via (i) and (ii), we only have to show that 
condition (c) remains true. 

For the purpose of proving (c), assume that the original proof outline sat- 
isfies condition (c) and suppose we are given a segment t from some assertion 
{3d : p) to some assertion (3d : g) in the transformed proof outline. As the 
transformation affects only the form of single statements and assertions but not 
the global structure of the proof outline, there is a corresponding segment s from 
p to g in the original proof outline such that the modification s of s equals t. 
By assumption, the original proof outline satisfies condition (c); thus, p implies 
wlp(s, g). We can now show the desired implication by 




(3d : p) 

(3d : wlp(s,g)) 
wlp(S, (3d : g)) 
wlp(t, (3d : g)) 



p wlp(s, g), monotonicity 
Lemma 4.2 
t = s. 



□ 



5 A Further Example 

Let g = {V,E) be an undirected and loop-free graph and assume that the call 
ngb{x) computes the set {y & V \ {x,y} G E} of all neighbour vertices of vertex 
X. A set of vertices of g is called independent if no two vertices in it are connected 
via an edge from E. To derive a program for computing such a set S, we start 
with the assertion 



S independent set oi g = {V, E) 



(7) 
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as post-condition post{S). Using a new variable X, then we generalize (7) to 

X CV and S independent set of gx = {X, Ex) , (8) 

where Ex = {e G E \ e C X}, i.e., gx is the subgraph of g generated by X. 
Choosing the conjunction of (8) and the assertion 

\/ X GV\X,y G S : {x,y} ^ E (9) 

as loop invariant inv{S, X), it is straightforward to derive the program for com- 
puting S shown in the following valid proof outline: 

{ true } 

^:=0;X:= 0; 

{ inv{S, X) } 

while X ^ V do (ISi) 

x:GV\X; 

S := S U {x}; X := X U ngb{x) U {x} od 
{ post{S) } . 

The definedness of the non-deterministic assignment x :G U \ X in this proof 
outline follows from the assumption U 0, the part X C V of the loop invariant, 
and the condition of the while-loop. Termination of the while-loop is obvious. 

Like the minimum vertex cover problem of Section 2, the problem of com- 
puting an independent set of maximum size is A^P-hard and the program of the 
proof outline (ISi) implements a well-known approximation algorithm proposed 
and studied by Wei [19]. 

Now, we formally analyze the worst-case behaviour of Wei’s algorithm using 
our method. To this end, we enrich the program of (ISi) by an auxiliary variable 
U, which consists of all the sets ngb{x) U {x} which are added to X on all 
iterations of the while loop. This step leads to a first strengthening of the original 
loop invariant inv{S,X): we add the conjunct 

X = [j^^^u. ( 10 ) 

Let A{g) = maxx^v \n'gb{x)\ be the so-called degree of the graph g. It is ob- 
vious that each set in U has at most A{g) + 1 elements and we add also the 
corresponding assertion 



y u G U : \u\ < A{g) + 1 (11) 

to the original loop invariant. Finally, we notice that whenever some set ngb{x)U 
{x} is added to U, the vertex x is added to S. Due to its choice via the assignment 
X :G V \ X and assertion (8), x is not yet a member of S. Thus, S cannot be 
smaller than U. The corresponding estimation 






(12) 
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is the third addition to the original loop invariant. Altogether, we obtain the fol- 
lowing proof outline with auxiliary variable U and a loop invariant inv{S, X, U) 
given as conjunction of the assertions (8) to (12); its validity proof is rather 
simple since it contains all necessary information: 

{ true } 

5:=0;X:=0;C/ 

{ inv{S, X, U) } 
while X ^ V do 
x:GV\X; 

S:=SU{x};X 
{ post{S) }. 

Now, we are able to estimate the worst-case behaviour of Wei’s algorithm 
formally. Assume inv{S, X,U) and X = V and let Sopt be the size of a maximum 
independent set of g. Then, we obtain 

Sopt < |V"| = I U u| < ^ |u| < \U\ * {A{g) -h 1) < |S'| * {A{g) + 1) . 

«ec/ iiGf/ 

Here the second step follows from assertion (10) and the loop’s exit condition 
X = V and the fourth and fifth step use assertions (11) and (12), respec- 
tively. Hence, the proof outline (IS 2 ) remains valid if its post-condition post{S) 
is strengthened to post'{S) by adding the conjunct 

Sopt < \S\ * {A{g) + 1) . (13) 

Now the auxiliary variable U can be eliminated using steps (i) and (ii) of Section 
4 and this, finally, yields the following valid proof outline for Wei’s algorithm 
which includes a worst-case estimation in its post-condition as desired: 

{ true } 

S-.= tti-X-.= 0; 

{ 3 17 : inv{S,X,U) } 

while X do (IS3) 

cc :G y\7f; 

S := S LI {x}; X := X U ngb{x) U {a;} od 
{ post'(S) } . 

We sketch some variants of Wei’s algorithm in the remainder of this section. 
They are based on a slight modification of the above estimation, viz. 

Sopt < |k^| = I I J w| < 1^1 < |17| * max |m| < [S'! * max 1^1 . 

u^U u^U 

u£U u£U 

From this property, we get max„gc/ |m| as a worst-case bound of Wei’s algorithm 
which is potentially better than the previous bound A{g) + 1. This maximum 



(IS2) 



:= X U ngb{x) U {cc}; U := U U {ngb{x) U {x}} od 
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is not known in advance, but it can easily be computed as a further result. A 
corresponding modification of the proof outline (IS 2 ) followed by the elimination 
of the auxiliary variable U leads to 

{ true } 

S := 0; A := 0; s := 0; 

{ 3 C/ : inv{S,X,U,s) } 

while X V do (IS4) 

x:€V\X; 

S := S U {x}; X := X U ngb{x) U {x}; s := max{s, \ngb{x) U {x}|) od 
{ post{S,s) } . 

Here the maximum max^gc/ |u| is stored in the variable s and the postcondition 
post{S,s) consists of the conjunction of the assertion (7) and the estimation 

Sopt < l-S”! * s. (14) 

Furthermore, the assertion inv{S, X,U, s) occurring in the loop invariant is ob- 
tained from the assertion inv{S,X,U) in (IS 3 ) by replacing (11) with 

s = max |m| . (15) 

u^U 

With this information, it is rather simple to show that (IS 4 ) is indeed a valid 
proof outline. Of course, the program of (IS 4 ) can slightly be improved by the 
use of a further variable which avoids the two-fold evaluation of the expression 
ngb{x) U {x}. 

By a little modification of the hitherto derivation, the computed worst-case 
bound can be improved as follows: instead of collecting all sets ngb{x)VJ{x} in U, 
we only collect their “non- visited parts”. That is, we replace the assignment U := 
UU{ngb{x) U {x}} by U := U U {{ngb{x)\X) U {x}} in the proof outline (IS2). 
To minimize the value of |m| further, we refine the non-deterministic 

assignment x :€ H \ A of (IS2) and pick now (via a simple loop) the vertex x in 
such a way from R\ A that the size of the set ngb{x) \ A is minimal. Obviously, 
both steps do not affect the invariance property of inv{S,X,U). Hence, the 
modified proof outline is also valid. Starting with this proof outline, we obtain 
the desired algorithm following the above derivation of (IS4) from (IS2). 

To choose in each iteration a node of minimal degree in the non- visited part of 
the graph is a common heuristic in connection with Wei’s algorithm. The idea, 
however, to enrich the algorithm by a variable s that computes the resulting 
worst-case bound and the formal correctness proof seems not to appear in the 
previous literature. 

6 Concluding Remarks 

When verifying approximation algorithms, we are particularly interested in es- 
timates for the maximal deviation of their results from optimal solutions of the 
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given problem. While the informal feasibility proofs found in the literature on 
algorithmics can usually be reformulated as formal assertional proofs straight- 
forwardly, the informal proofs of worst-case bounds often refer to entities that 
are not present in the program and are thus difficult to formalize. As a solution, 
we proposed in this paper to collect additional information in auxiliary variables 
inserted into the program which can be referred to in assertions. These auxiliary 
variables are introduced solely for the purpose of the formal assertional proof 
and are not meant to stay in the executed version of the program. Therefore, 
we showed how they can be eliminated from proof outlines without affecting va- 
lidity. Their elimination also allows references to non-constructive or expensive 
operations in assignments to auxiliary variables. 

When we develop approximation algorithms in the way proposed in this paper 
we start from a partial specification (that specifies only feasibility of the result) 
and strengthen it during the program development (to account for the achieved 
approximation bound) with the aid of auxiliary variables. There are other ap- 
plication areas where it is natural to proceed in a similar fashion. Examples 
include development of probabilistic algorithms and reasoning about run-time 
of programs. Indeed, it is an old idea to use a designated variable in order to 
model run-time consumption of programs and to reason about it [16, 12, 15]. 

Our approach can be seen as a particular application of the well-known “in- 
vent and verify” technique for program development combined with transforma- 
tional programming. In doing so, sometimes the specific form of the assignments 
to auxiliary variables formally can be calculated using, e.g., the postcondition 
and/or the invariant (s). However, the usual way to introduce auxiliary variables 
is by an “invent” step. In the latter case only the “verify” step is a formal 
one. The elimination of auxiliary variables corresponds to the application of a 
schematic transformation rule. 

The approach has been applied to many other, more complex approximation 
algorithms besides the two examples considered in this paper, in particular, to 
all approximation algorithms discussed in [17]. This includes e.g., the formal 
development of a program implementing Chvatal’s well-known approximation 
algorithm for set covering. (A description of this algorithm in the common in- 
formal style can be found in [3].) 

When investigating the formal development and verification of approximation 
algorithms we have also discovered a new result viz. an approximation algorithm 
for the bin packing problem which possesses | as absolute worst-case approxima- 
tion bound and runs in linear time^. It follows the Best Fit idea. In contrast with 
the original approach, however, it works with two partial solutions P\ and P 2 
instead of one and two auxiliary bins Bi and B 2 - one for each partial solution. 
Roughly speaking, it proceeds as follows. First, the objects are packed one by 



^ As shown in [18], there is no approximation algorithm for the bin packing prob- 
lem with an absolute approximation factor smaller than |, unless P = NP. But all 
approximation algorithms with this - in all probability - optimal absolute approxi- 
mation factor which can be found in the literature are non-linear; the best running 
time is 0{n * logn) with n as number of objects. See the overview paper [4]. 
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one into B\ until its capacity would be exceeded by the insertion of some object 
u. In this situation the contents of Bi is inserted into Pi, the bin Bi is cleared, 
u is packed into B 2 , and the process starts again with the remaining objects. 
If, however, the insertion of u would lead to an overfilling of Bi as well as B 2 , 
then additionally the contents of B 2 is inserted into P 2 and u is packed into the 
cleared i? 2 - This “book-keeping” in combination with a suitable selection of the 
next object (based on a partition of the objects into small and large ones at the 
beginning of the algorithm) allows one to avoid the costly search of a bin the 
next object will fit in optimally. The decisive idea for proving the bound | is to 
use a function / which yields for a bin B of P\ the unique object whose insertion 
into B would lead to an overfilling. 

Details of the algorithm can be found in [2], where its correctness (i.e., the 
feasibility of the result and the absolute approximation factor |) formally is 
verified using the assertion technique. In doing so, / is not used as an auxiliary 
variable but as a logical variable in assertions. It is, however, not hard to develop 
the algorithm in the style proposed in the current paper using an auxiliary 
variable that holds the function /. We believe that this development is clearer 
and, thus, easier to follow than the original one. 

Besides their use in approximation algorithms we have investigated also some 
other applications of auxiliary variables, for instance, their utility for formal ter- 
mination proofs and for program specialization. We illustrate the latter applica- 
tion by a somewhat academic example. Consider the following proof outline for 
a program calculating quotient and remainder of two positive integers x and y 
by iterated subtraction: 



{x>0Ay>0} 
q := 0;r := x; 

{0<r A x = q- y + r} 
while r > j/ do 
q := q + l;r := r — y od 
{ X = q ■ y + r A 0 < r < y } 

If we weaken the post-condition to r = a; mod y, then q becomes an auxiliary 
variable. Subsequently applying elimination leads to the following proof outline: 

{a;>0Aj/>0} 
r := x; 

{ {3q : 0 < r A x = q ■ y + r) } 
while r > y do 
r := r — y od 
{ r = a; mod y } 

The underlying program computes just the remainder of integer division, i.e., 
is a specialization of the program of the first proof outline. 

Interestingly, auxiliary variables are of crucial importance for the approach 
of Owicki aud Cries to verification of concurrent programs: they are necessary 
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for achieving completeness [8]. Therefore, proof rules for elimination of auxiliary 
variables are found in connection with that method. Rule 17 in [1, p. 193], for 
instance, reads as follows, where Sq is the program obtained from program S by 
deleting all assignments to auxiliary variables. 

M ^ {g} 

M So {(?} ■ 

This rule is usually proved to be correct by referring to an underlying opera- 
tional semantics; see, e.g., the proof of Lemma 5.17 in [1, p. 196]. We believe 
that our proof of the correctness of elimination on the level of predicate trans- 
formers is much more elegant. Moreover, our result is stronger. We not only 
show that partial correctness is preserved but validity of whole proof outlines, if 
auxiliary variables are removed from the programs and existentially quantified 
in the assertions. 

Auxiliary variables can also be used for performing data refinements. In do- 
ing so, firstly, concrete variables intended to replace abstract variables are added 
to the program as auxiliary variables and updated in parallel with the abstract 
variables such that a coupling invariant is preserved. In a second step then the 
program is algorithmically refined in such a way that the abstract variables be- 
come auxiliary variables. Finally, the abstract variables are eliminated. Morgan 
[14] investigates this method in the context of predicate transformer semantics. 
However, he does not describe a systematic transformation for eliminating aux- 
iliary variables from proof outlines as we do here. 

To sum up: due to the experiences gained so far, we believe that auxiliary 
variables in combination with proof outlines and our elimination procedure are 
a valuable means for formal program development, verification and proof docu- 
mentation. 
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Abstract. We describe in this paper the formal verification, using the 
ACL2 system, of a syntactic unification algorithm where terms are rep- 
resented as directed acyclic graphs {dags) and these graphs are stored 
in a single-threaded object (stobj). The use of stobjs allows destructive 
operations on data (thus improving the performance of the algorithm), 
while maintaining the applicative semantics of ACL2. We intend to show 
how ACL2 provides an environment where execution of algorithms with 
efficient data structures and formal reasoning about them can be carried 
out. 



1 Introduction 

The ACL2 system includes a programming language, a logic for formal reason- 
ing about the properties of the functions defined in the language, and a theorem 
prover supporting mechanized reasoning in the logic. The ACL2 programming 
language is an extension of an applicative subset of Common Lisp and the logic 
is a first-order logic with equality, without quantifiers (all the formulas are im- 
plicitly universally quantified). 

Since the programming language is applicative, logical arguments about the 
correctness and termination of algorithms are made as they are in ordinary math- 
ematics, without the complications incured by consideration of state. Notwith- 
standing, it is possible to declare some objects in the language as single-threaded 
objects (in the sequel, stobjs) and perform destructive updates on them. When 
an object is declared to be single-threaded, ACL2 enforces certain syntactic re- 
strictions on its use, ensuring that in every moment only one copy of the object 
is needed. With these restrictions, the destructive updates are consistent with 
the applicative semantics of ACL2. Using stobjs we can combine efficient im- 
perative implementations with the semantic of functional languages to reason 
about these implementations. 

* This work has been supported by project TIC2000-1368-C03-02 (Ministry of Science 
and Technology, Spain) and FEDER funds. 
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In this paper we present a case study where we use ACL2 to implement and 
verify a unification algorithm. A standard approach in the implementation of 
unification is to represent terms as directed acyclic graphs {dags in the following), 
allowing some amount of structure sharing; in this way, it is not needed to build 
new terms during the unification process, but merely update (destructively) the 
graph, thus improving the performance of the algorithm. In our implementation, 
the dags will be stored using a stobj. 

To achieve the formal proof, we follow the well-known methodology of compo- 
sitional reasoning. As a first step, we reason about unification at a very abstract 
level, without entering in details related to the control of the algorithm or the 
data structures used. By stepwise-refinement, we finally obtain the proof of the 
desired properties of our concrete unification algorithm. 

Another interesting point in this case study is the use of a new feature in 
ACL2 (the mbe feature) that associates an “executable body” with a (possibly 
different) “logical body”. This association will be allowed by the system after 
proving that on the intended domain of the function, the executable body and 
the logical body are equal. We describe this new feature of ACL2, and explain 
how it can be used to improve the execution efficiency of the verified unification 
algorithm. 

Although we will not give an introduction to ACL2, we will comment the 
relevant questions in passing, when needed. An excellent introduction to ACL2 
is [5]. A detailed description of the system can be found in the manual, available 
in [6]. We will assume the reader familiar with Common Lisp. Due to the lack of 
space, we will not give here details about the proofs obtained and some function 
definitions will be omitted. We urge the interested reader to consult [11], where 
the complete development (with a detailed description) is available. 

2 Dag Unification 

We briefly review some basic concepts about (syntactic) unification, a funda- 
mental process upon which many methods of automated deduction are based. A 
complete description of the theory of unification can be found in [2] . 

An equation is a pair of first-order terms, denoted as t\ « t 2 , and a system 
of equations is a finite set of equations. A substitution cr is a solution of t\ « t 2 
if cr(ti) = (j{t 2 ) and it is a solution of a system of equations S if it is a solution 
of every equation in S. Given two substitutions cr and 5, we say that a is more 
general than <5 if there exists a substitution 7 such that S = jo a, where o denotes 
functional composition. We say that a solution of S' is a most general solution if 
it is more general than any other solution of S. Two terms ti and t 2 are unifiahle 
if there exists a solution (called unifier) of the system {t\ « ^2}- A most general 
unifier {mgu in the sequel) of ti and t 2 is a most general solution of that system. 
A unification algorithm is an algorithm that decides whether two given terms 
are unifiable, and in that case it returns a most general unifier. 

Essentially, the unification algorithm we have implemented is based on the 
relation given by the set of transformation rules presented in Figure 1 (known 
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Fig. 1. Martelli-Montanari transformation system 



as the Martelli-Montanari transformation system). This system acts on pairs of 
systems of equations of the form S; U. Intuitively, the system S can be seen as a 
set of pairs of terms to be unified, and the system [/ as a (partially) computed 
unifier^ (we say that the pair S;U is a unification problem). The symbol T 
represents unification failure. Starting with the pair of systems S; 0, these rules 
can be (non-deterministically) applied iteratively, until either a pair of systems of 
the form 0; {7 or T is obtained. It can be proved that this process must terminate 
and that S has a solution if and only if T is not derived; in that case U is a, most 
general solution of S. Thus, a unification algorithm can be designed choosing an 
strategy to apply the rules, starting with the pair of systems {t\ « t^}', 0, where 
t\ and t 2 are two given input terms. 

In [10] we had defined and verified a unification algorithm based on this set 
of transformation rules, as part of an ACL2 library with formal proofs of the 
lattice-theoretic properties of first-order terms. In that library, terms are repre- 
sented in prefix notation, using lists (except variables, which are represented by 
atomic objects). For example, the term f{x, g{y),h{x)) is represented by the list 
(f X (g y) (h x)). Substitutions are represented as association lists, and sys- 
tems of equations as lists of dotted pairs of terms. In the sequel, this represen- 
tation of terms and substitutions in prefix form, using lists, will be referred to 
as prefix representation or prefix notation. 

Using the prefix representation, a unification algorithm may be inefficient 
in some situations. Consider, for example, the following standard parameterized 
unification problem, which we will call 

p{Xn, ...,X 2 ,Xi)Ki p{f{Xn-l,Xn-l), ■■■, f {xi, Xi) , f {xq, Xq)) 

A mgu of this problem is {a:i f(xo, xg), X 2 ^ f{f{xo, xg), /(xq, xg)), . . .}, 
which maps each variable Xi to a complete binary tree of height i. This mgu 
can be obtained by repeatedly applying the Eliminate rule of =^„. If we use the 
prefix representation of terms, it will be necessary to reconstruct the instantiated 
system of equations, each time the rule is applied. 

^ We will identify a system of equations of the form {xi « ti,. . . ,Xn ~ t„}, where 
the Xi are variables, with the substitution {xi ti, . . . ,x„ tn}. If none of the Xi 
appear in any of the tj, we say that the system is in solved form. Note that every 
system in solved form is a mgu of itself. 
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The standard approach to deal with this problem is to use term dags where 
variables are shared. For example, the following graph represents the equation 
f{h{z),g{h{x),h{u))) « f{x,g{h{u),v)). Nodes are labeled with function and 
variable symbols, and outgoing edges connect every node with dags represent- 
ing its immediate subterms. We can naturally identify the root node of a term 
dag with the whole term. Note also that there is a certain amount of structure 
sharing, at least for the repeated variables^: 




To implement a unification algorithm with this term representation, the main 
idea is never to build new terms but only create pointers. In particular, the 
Eliminate rule can be implemented adding a pointer linking the variable with 
the term to which this variable is bound; in that way no reconstruction of the 
term is required in the application of a substitution. In the graph above, these 
pointers are represented by dashed arrows. The binding for a variable can be 
determined by following the pointers traversing the graph depth first, from left 
to right. In this case, the substitution represented is {x i— *■ h{z),u i— *■ h{z),v i— > 
h{h{z))}, which is a mgu of f (h{z) , g{h{x) , h{u))) and f {x , g{h{u) , v)) . 

3 An ACL2 Implementation 

The implementation described here is based on the Pascal implementation given 
in section 4.8 of [1]. The main difference is that instead of a record with pointers, 
we use a single-threaded object. This stobj is a structure called terms-dag with 
only one field: an array called dag (whose size can be modified dynamically). 
This array is used to store the unification problem in dag form: 

(def stobj terms-dag 

(dag :type (array t (0)) : resizable t)) 

The effect of this ACL2 event is to introduce the stobj terms-dag and its 
associated recognizers, creator, accessors, updaters, and length and resize func- 
tions of the array field. In particular, given an index i (a natural number) cor- 
responding to a cell of the dag array, the expressions (dagi i terms-dag) and 
(update-dagi i v terms-dag) access and update (with value v) respectively 
the j-th cell of the dag array. These operations are done in constant time and the 

^ It should be remarked that this is simply one possible representation in which only 
variables are shared; this is not the most compact representation, but the one that 
serves as the basis of the verified unification algorithm. 
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update is destructive. Nevertheless, from the logical point of view, the array can 
be thought as a list, with an applicative semantic (that is, as if in every update a 
new object were created) . This is possible due to the fact that in ACL2, the use 
of stobjs is syntactically restricted, ensuring that in every moment only one copy 
of the object is needed. Roughly speaking, these syntactic restrictions enforce 
that the only references to the stobj are done via its name (terms-dag, in this 
case) . See [4, 6] for further information about stobjs in ACL2 and the restrictions 
on its use. 

Each node in the graph is represented by a cell in the dag array of the stobj. 
Thus, a node in the graph can be identified with an array index. Each cell stores 
the label and the successors of one node, in the following way: 

— If node i represents an unbound variable x, then (dagi i terms-dag) con- 
tains a dotted pair of the form (x . t). 

— If node i represents a bound variable, then (dagi i terms-dag) contains 
an index n pointing to the root node of the term to which the variable is 
bound. 

— If node i is the root node of a non-variable term /(ti, . . . , t^), then (dagi i 

terms-dag) is a dotted pair of the form (/ . 0, where I is the list of the 
indices corresponding to the root nodes of ti , . . . , . 



In this way, we can store a unification problem using the terms-dag stobj. 
For example, if we store the term equ{f{h{z),g{h(x), h{u))), f{x, g{h{u), v))) the 
significant cells of the dag array are: 
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We can naturally identify an array index with the term whose root node is 
stored in the corresponding array cell. Taking advantage of this idea, we can 
define a function (called dag-transf orm-mm-st, figure 2) that applies one step 
of the transformation relation to a unification problem stored in terms-dag. 

Let us precise about the behavior of dag-transf orm-mm-st. In addition to 
the stobj, this function receives as input a (non-empty) system of equations S 
to be unified and a partially computed substitution U. The key point here is 
that S and U only contain indices pointing to the terms stored in terms-dag. 
In particular, S is a list of pairs of indices, and U is a list of pairs of the form 
ix . n) where a; is a variable symbol and n is the index of the node for which 
the variable is bound (we say that S is an indices system and U an indices 
substitution). Depending on the pair of terms pointed to by the first equation 
of S^, one of the rules of =>u is applied. The function returns a multivalue with 
the following components, obtained as a result of the application of one step 
of transformation: the resulting indices system of equations to be solved, the 

® Note that the indices of the selected equation are dereferenced using the function 
dag-deref-st, which follows a chain of instantiations until it reaches an unbound 
variable or non- variable node. 
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(defun dag-transf orm-mm-st (S U terms-dag) 

(declare (xargs :stobjs terms-dag)) 

(let* ((ecu (car S)) 

(tl (dag-deref-st (car ecu) terms-dag)) 

(t2 (dag-deref-st (cdr ecu) terms-dag)) 

(R (cdr S)) 

(pi (dagi tl terms-dag)) 

(p2 (dagi t2 terms-dag))) 

(cond 

((= tl t2) (mv R U t terms-dag)) 

( (dag-variable-p pi) 

(if (occur-check-st t tl t2 terms-dag) 

(mv nil nil nil terms-dag) 

(let ((terms-dag (update-dagi tl t2 terms-dag))) 

(mv R (cons (cons (dag-symbol pi) t2) U) t terms-dag)))) 
((dag-variable-p p2) 

(mv (cons (cons t2 tl) R) U t terms-dag)) 

((not (eql (dag-symbol pi) 

(dag-symbol p2))) 

(mv nil nil nil terms-dag)) 

(t (mv-let (pair-args bool) 

(pair-args (dag-args pi) (dag-args p2)) 

(if bool 

(mv (append pair-args R) U t terms-dag) 

(mv nil nil nil terms-dag))))))) 



Fig. 2. One step of transformation 

resulting indices substitution, a boolean (if _L is obtained, this value is nil) and 
the stobj terms-dag. Note that only when Eliminate is applied, the stobj is 
updated, causing the corresponding variable to point to the corresponding term. 

With dag-transf orm-mm-st as its main component, we can define the uni- 
fication algorithm. In short, this function, called dag-mgu, receives as input two 
terms in prefix form; after storing these terms as directed acyclic graphs in the 
stobj (previously resizing the dag array properly), it iteratively applies the func- 
tion dag-transf orm-mm-st until either non-unifiability is detected or there are 
no more equations to be solved. In this last case, the returned substitution (in 
prefix form) is built from the final contents of dag, following the pointers of the 
instantiated variables. The following are two examples obtained with dag-mgu. 
Note that the function returns two values: the first one is a boolean indicating 
whether the terms are unifiable or not, and, in case of unifiability, the second is 
the mgu. 

ACL2 !> (dag-mgu ’ (f (h z) (g (h x) (h u))) ’ (f x (g (h u) v))) 

(T ((V . (H (HZ))) (U . (HZ)) (X . (HZ)))) 

ACL2 !> (dag-mgu ’ (f y x) ’ (f (k x) y)) 

(NIL NIL) 
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It is worth pointing out that the syntactic requirements needed to ensure the 
single-threadedness of the ACL2 functions that use stobjs are naturally met in 
this algorithm. See [11] for the definitions of all the auxiliary functions used. Since 
the ACL2 language is a subset of Common Lisp (and we have verified guards^), 
the defined algorithm can be compiled and executed in every compliant Common 
Lisp, with the appropriate ACL2 files loaded. 

4 The Formal Properties of the Unification Algorithm 

Once defined the function dag-mgu, we use the ACL2 logic and its theorem 
prover to formally establish that it computes the most general unifier of two 
terms if and only if the terms are unifiable: 

(defthm dag-mgu-completeness 

(implies (and (term-p tl) (term-p t2) 

(equal (instance tl sigma) (instance t2 sigma))) 
(first (dag-mgu tl t2)))) 

(defthm dag-mgu- soundness 

(implies (and (term-p tl) (term-p t2) 

(first (dag-mgu tl t2))) 

(equal (instance tl (second (dag-mgu tl t2))) 

(instance t2 (second (dag-mgu tl t2)))))) 

(defthm dag-mgu-most-general-solution 
(implies (and (term-p tl) (term-p t2) 

(equal (instance tl sigma) (instance t2 sigma))) 
(subs-subst (second (dag-mgu tl t2)) sigma))) 

The function instance defines the application of a substitution to a term, 
and the predicate subs-subst defines the relation “more general than” between 
substitutions. The predicate term-p recognizes those ACL2 objects that rep- 
resent first-order terms in prefix notation. Note that the basic theory used to 
state the properties is built on the terms represented in prefix notation. For a 
detailed description of this theory, see [10]. Also the input and the output of the 
function dag-mgu are terms and substitutions in prefix notation. But it has to 
be emphasized that internally, the main process is carried out on term dags. 

The first theorem, dag-mgu-completeness, establishes that the algorithm 
returns t (as its first value) if the input terms are unifiable®. The theorem dag- 
-mgu-soundness establishes that in that case it returns (as its second value) a 
unifier of both terms. Finally, the theorem dag-mgu-most-general-solution 
establishes that the returned substitution is more general than any other unifier 
of both terms. These three proved theorems constitute a formal proof of the 
correctness of the algorithm. 

^ The notion of guard of a function will be explained in section 6. 

® Note that the variable sigma, although implicitly universally quantified, can be seen 
as existentially quantified, since it only appears in the hypothesis of the theorem. 
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5 Comments about the Proof 

In this section, we give an overview of the proof process. To emphasize the “com- 
positional reasoning” methodology followed, we have structured it in subsections. 
First we begin with the subsections describing properties of the algorithm at a 
more abstract level. These abstract properties can be gradually concretized to 
finally obtain the theorems shown in the previous section. 



5.1 Reasoning about the Reduction 

One step of transformation of is determined by the rule applied and the 
equation selected. To formalize this intuitive idea in ACL2, we define by 
means of operators. In this context, an operator is a dotted pair of the form 
{name . i) where name is one of the rule names in figure 1 and z is a natural 
number, corresponding to the z-th equation of the system. Thus, the transfor- 
mation can be seen as applying one operator to a unification problem. This 
operator can be applied whenever the conditions of the particular rule applied 
are met. For example, the operator (eliminate . 3) can be applied to a uni- 
fication problem if its third equation is of the form x ~ t and x does not occur 
in t. The following two functions formalize this idea in ACL2: 

• (unif-legal-pr upl op), checking the conditions needed to apply a given 
operator op to a unification problem upl (in prefix notation). 

• (unif-reduce-one-step-pr upl op), returning the transformed unifica- 
tion problem (in prefix notation) after applying op to upl. 

With this operator-based representation we proved in ACL2 the main prop- 
erties of =^„. That is: a) the set of solutions of a unification problem is preserved 
in each step, b) if the second system of a unification problem is in solved form, 
then the transformed unification problem has its second system in solved form, 
and c) the transformation relation is terminating. These properties are more 
naturally proved with terms represented in prefix form, and this allows us to 
reuse part of the theory developed in [10] for the verification of the applicative 
unification algorithm. 

Having proved the main properties of one-step transformations, we can easily 
extend these properties to finite sequences of transformations. In particular we 
prove that if {t\ « ^ 2 };® 0; cr, then <t is a mgu of t\ and ( 2 , and if {t\ « 

( 2 }; 0 =?ii T, then t\ and (2 are not unifiable. Note that in our formalization, a 
sequence of transformation can be identified with a list of (legal) operators. 

It is remarkable that these results do not deal with control or data structures 
issues: to prove the correctness of a concrete unification algorithm, it suffices to 
show that the actions of the algorithm can be simulated by a finite sequence of 
transformations w.r.t. =^„. That is the main advantage of rule-based specifica- 
tions: they allow to prove the essential properties of the procedure without the 
burden of technical implementation issues. 
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5.2 Dags and Well-Formedness Conditions 

In order to translate the main properties of to our implemented algorithm, 
we have to relate the information stored in the terms-dag stobj with the terms 
in prefix notation it may represent. In general, not every possible contents of the 
dag array represent first-order terms. The main reason is that the graph could 
contain cycles, and in that case, no first-order term is represented by the cells 
of the array. 

This means that we have to define predicates to recognize the properties 
needed to ensure that the array contents represent a first-order term; the main 
of those properties is acyclicness, ensuring that the graph stored in the dag 
array is actually a dag. Some other well-formedness properties are also needed 
(for instance the sharing of variables). 

Another important reason why these well-formedness conditions are needed 
has to do with the restrictions imposed by the ACL2 logic in its principle of 
definition: new function definitions are admitted as axioms in the logic only if 
there exists a measure in which the arguments of each recursive call decrease 
with respect to a well-founded relation, ensuring in this way that the function 
terminates on all inputs (and consequently no inconsistencies are introduced by 
new function definitions). For example, a function implementing “occur-check” 
(looking for the occurrence of a given variable in a term) may not terminate if the 
graph stored in the array contains cycles. The same happens with dereferencing 
or even with the function that iteratively applies dag-transf orm-mm-st. Thus, 
these functions require an explicit check to verify that the stobj does indeed 
represent an acyclic graph, ensuring their termination. We will comment more 
about this point in section 6. 

For these reasons, we have developed a library of results about directed 
acyclic graphs. For example, this library contains the definition of the function 
dag-p; this function checks that a given graph (stored following the conventions 
described in section 3) does not contain cycles. It is implemented as a standard 
depth-first search algorithm, looking for cycles in the graph. The following the- 
orems establish that a graph g verifies the dag-p condition if and only if does 
not contain cycles: 

(defthm dag-p-soundeness 
(implies (not (dag-p g) ) 

(cycle-p (one-cyclic-path g) g) ) ) 

(defthm dag-p-completeness 
(implies (cycle-p p g) 

(not (dag-p g)))) 

Some other general definitions and results about dags are part of this library. 
See [11] for details. Having dag-p as its main auxiliary function, we can define a 
function checking the well-formedness conditions of a unification problem given 
in dag form: (well-f ormed-upl dag-upl) is true if and only if dag-upl is a 
three-element list such that its first element is an indices system, the second 
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is an indices substitution and the third is an acyclic term graph with shared 
variables. In the following, by well-formed dag unification problem we mean an 
ACL2 object that satisfies well-f ormed-upl. Every well-formed dag unification 
problem has a unification problem in prefix notation associated. 

One technical issue is worth pointing out. The main advantage in the rea- 
soning about stobjs is that from the logical point of view, an array field of a 
stobj is like a list whose elements are the contents of the array®. For this, we 
can reason about dags as if the graph were a list, instead of an array field of a 
stobj. For example, the function dag-p above is defined on lists. In addition to 
simplifying the formulation of the theorems, this allows to define some proper- 
ties about graphs following the usual “car-cdr” recursion style. This style would 
not be allowed if the definition were on the stobj, due to the syntactic restric- 
tions imposed by ACL2 on stobjs. Of course, those functions that are going to 
be executed have to be defined on the stobj; but we define a “list version” for 
reasoning and then translate the main properties proved to the “stobj version” 
(for example, we define a function dag-p-st on the terms-dag stobj, logically 
equivalent to dag-p). 



5.3 Compositional Reasoning 

Since our implemented algorithm acts on terms represented as dags, we must 
now define in ACL2 the behavior of the relation acting on well-formed dag 
unification problems. As in subsection 5.1, we adopt an operator based approach. 
That is, we define the following two functions: 

• (unif-legal-d dag-upl op), checking the conditions needed to apply a 
given operator op to a dag unification problem dag-upl. These conditions 
are similar, for each rule, to the conditions checked by the function dag- 
-transf orm-mm-st (figure 2) before applying a transformation. 

• (unif-reduce-one-step-d dag-upl op), returning the transformed dag 
unification problem obtained after applying op to dag-upl. These trans- 
formations are similar, for each rule, to the transformations performed by 
the function dag-transf orm-mm-st. 

Instead of proving the properties of these transformations reasoning directly 
with the definitions of the above functions (which can be difficult due to the more 
sophisticated data structures used), we can translate the properties proved for 
the transformations on the prefix representation, using compositional reasoning. 
More precisely, denoting as UPLp the set of unification problems represented in 
prefix form, and as UPLd the set of well- formed dag unification problems, the 
key point is to prove that the following diagram commutes: 



For example, the accessors and updaters are logically equivalent to the list functions 
nth and update-nth which, respectively, access and update the contents of a list. 
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UPLp UPLp 



dp 



dp 



UPLd 



UPLd 



Here dp is a function such that given a well-formed dag unification problem, it 
returns the corresponding unification problem in prefix form; and =^u,d de- 
note, respectively, the relation defined on the prefix representation and on the 
dag representation. The commutativity of the above diagram is formally estab- 
lished in ACL2 by the following theorem (the function upl-as-pair-of-systems 
plays the role of the function dp in the diagram): 



(defthm conmut at ivity-of -diagram-prefix-dag 
(implies (and (well-f ormed-upl dag-upl) 

(unif-legal-d dag-upl op)) 

(and (well-f ormed-upl (unif-reduce-one-step-d dag-upl op)) 
(unif-legal-pr (upl-as-pair-of-systems dag-upl) op) 
(equal (upl-as-pair-of-systems 

(unif-reduce-one-step-d dag-upl op)) 
(unif-reduce-one-step-pr 

(upl-as-pair-of-systems dag-upl) op))))) 



This theorem establishes that: 



• The well-formedness property of dag unification problems is preserved by 
the transformation rules. 

• If the conditions needed to apply a rule to a well-formed dag unification 
problem are met, then the conditions required to apply the same rule to the 
corresponding unification problem in prefix form are also met. 

• In that case, the transformed unification problem obtained applying the rule 
to the prefix representation is the same as the unification problem in prefix 
form corresponding to the dag unification problem obtained applying the 
same rule to the dag representation. 

These properties allow us to easily translate the main properties described 
in subsection 5.1 to this more efficient data structure. In particular, it can be 
proved that we can obtain a most general unifier of two terms by exhaustively 
applying the rules of transformation on its dag representation. 



5.4 Final Steps 

Now that we have all the main pieces needed for the verification of the algorithm, 
we proceed as follows: 

• First, we define a function that, given two terms in prefix form, returns 
the corresponding dag unification problem. We must prove that this dag 
unification problem is well-formed. This result turned out to be one of the 
hardest part of all the verification process. 
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• Second, we show that the transformations performed by our unification al- 
gorithm can be simulated by a sequence of transformations of ^u,d- That 
is, we deal with the specific control (or selection strategy) of the algorithm. 
In our case, we always select the first equation, but any other strategy could 
work. In terms of operators, this means that we have to explicitly give a 
sequence of operators that, iteratively applied to the initial dag unification 
problem, obtains the same final dag unification problem as the implemented 
algorithm. Note that even though operators are used for defining the trans- 
formation relation, these are an intermediate concept used for reasoning, but 
not used by the unification algorithm. 

• Finally, since the above properties are established for the “dag-list version” 
of the algorithm, we translate the properties to the executable “dag-stobj 
version”, finally proving the formal properties presented in section 4. 

5.5 Quantifying the Proof Effort 

The ACL2 theorem prover supports mechanized reasoning in the ACL2 logic, 
being particularly well-suited for obtaining automated proofs based on induc- 
tion and simplification. The prover is automatic in the sense that once def thm is 
invoked, the user can no longer interact with the system. However, in a deeper 
sense, the system is interactive: usually, when proving non-trivial theorems, the 
user has to guide the prover by adding lemmas and definitions (used in subse- 
quent proofs as rewrite rules during the simplification process), or giving some 
hints to the defthm command, such as the scheme for a induction proof. 

A typical ACL2 proof effort consists of formalizing the problem in the logic 
and helping the prover to find a preconceived proof by means of a suitable set of 
rewrite rules. These rules can be found by inspecting the failed proofs: when the 
proof attempt deviates from the expected proof, usually a lemma is needed to 
deal with that part of the proof by simplification. This methodology produces a 
collection of lemmas (and definitions) leading the prover to the proof of the main 
result. Some of these lemmas are interesting by themselves and can be reused 
later in other parts of the development. This way of interacting with the system 
is called “The Method” by the authors of the system and it is explained in detail 
in [5]. We followed “The Method” in this case study. 

The table below shows some quantitative information about the proof effort, 
the number of definitions and theorems needed during the different stages of the 
verification process (we have not included in the table data of the basic theory 
about first-order terms): 



Phase 


Definitions 


Theorems 


Properties on the prefix representation 


24 


81 


Acyclic graphs 


37 


95 


Diagram commutativity 


39 


66 


Storing the initial terms in the graph 


34 


208 


Properties of the implemented algorithm 


43 


76 


Total 


177 


703 
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These numbers may give an idea of the complexity of the formalized theories 
and the degree of automation of the proofs obtained. We should say that most 
of the lemmas needed during the first phase were already proved in [10]. It is 
also remarkable (and somewhat surprising) the number of theorems needed to 
prove the properties of a function that stores the initial terms as directed acyclic 
graphs. 

6 Execution of the Algorithm 

As we have already said, ACL2 is a logic of total functions. That is, a proof of the 
termination of the function on all possible inputs is required for the definition 
to be accepted by the prover. In some cases, this means that a definition must 
include in its body an explicit check on their arguments, ensuring its termination. 
This check may seriously affect the execution performance of the function. Until 
the current ACL2 version 2.7, this was a weakness of the system that appeared 
when dealing with functions that only terminate on their intended domain, but 
not for every possible input. In the next ACL2 release, the new mbe feature 
(which stands for “must be equal”) overcomes that weakness: it allows to assign 
to a function an alternate “executable body” to that provided for the logic. 

We use mbe in this work, avoiding (for execution) the expensive well-formed- 
ness checks that are needed in the logical definitions of some of the functions of 
the dag unification algorithm. We explain this with an example. The following 
is the definition of the function dag-solve-upl-st, which iteratively applies 
steps of transformation to a given unification problem, until either there are no 
equations to be solved or unsolvability is detected: 

(defun dag-solve-upl-st (S U bool terms-dag) 

(declare 

(xargs :stobjs terms-dag 

: guard (well-f ormed-upl-st S U terms-dag) 

. . .) 

(MBE 
: logic 

(if (well-f ormed-upl-st S U terms-dag) 

(if (or (not bool) (endp S)) 

(mv S U bool terms-dag) 

(mv-let (SI U1 booll terms-dag) 

(dag-transf orm-mm-st S U terms-dag) 
(dag-solve-upl-st SI U1 booll terms-dag))) 

(mv nil nil nil terms-dag)) 

: exec 

(if (or (not bool) (endp S)) 

(mv S U bool terms-dag) 

(mv-let (SI U1 booll terms-dag) 

(dag-transf orm-mm-st S U terms-dag) 

(dag-solve-upl-st SI U1 booll terms-dag))))) 
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This defun defines the function in the logic using the body given by the 
: logic key argument, but when the function is evaluated on arguments of its 
intended domain (this intended domain is given by the : guard key) then the 
body given by the : exec key argument is used. The logical body needs an explicit 
check performed by the function well-f ormed-upl-st^, in order to ensure its 
termination (which it is not trivial to prove). This condition is expensive, since 
acyclicness is checked; moreover, if we use this logic body for execution, this 
expensive check would be evaluated in every recursive call, making execution of 
the function impractical. 

From the logical point of view (mbe ; logic logicbody :exec execbody) is 
equal to logicbody, so execbody is ignored for reasoning. But when the function is 
evaluated on its intended domain, the underlying Common Lisp uses the (hope- 
fully) more efficient execbody. The “intended domain” is specified in ACL2 by its 
guard, and the proof obligations generated by the guard verification mechanism 
ensure the soundness of using the executable body instead of the logic body. 

Guards in ACL 2 are used to specify the intended domain of a function. 
Although this specification is actually ignored by the logic, the guard verifica- 
tion mechanism allows to evaluate the function directly in Common Lisp. If the 
guards of a function are verified, then it is ensured that when the function is 
evaluated on arguments satisfying its guard, then all subsequent function calls 
during that evaluation will be on arguments satisfying the guard of the called 
function. The proof obligations generated by the guard verification mechanism 
ensure this property. Since the primitive Common Lisp functions of ACL2 has 
guards consistent with the Common Lisp specification, an ACL2 function with 
its guards verified is Common Lisp compliant and can be evaluated, on argu- 
ments satisfying its guard, directly in the underlying Common Lisp. 

The guard of the function mbe specifies that its two arguments are equal. 
Thus, when a function that uses mbe has its guard verified, then it is sound to 
use the executable body for execution, whenever the input arguments are in the 
intended domain specified by the guard. 

In addition to the above function, some of the auxiliary functions used by 
the implemented algorithm dag-mgu are defined in a similar way, using mbe (for 
example, occur checking or dereferencing). Since we have verified the guards of 
dag-mgu (and therefore the guards of all the functions used by the algorithm), 
all the expensive well-formedness checks are ignored when calling the function 
dag-mgu on two ACL2 objects representing terms in prefix form (the guard of 
dag-mgu). Note that the guard of the main top level function is very simple, and 
since guards are verified, it is not needed to evaluate the more expensive guards 
of its auxiliary functions in subsequent calls. 

We have tested the verified unification algorithm using the parameterized 
unification problem C/„ (presented in section 2). We compare its performance 
with the applicative algorithm defined in [10]. The problem [/„ is particularly 
well suited for the dag unification algorithm, since it is already in dag solved 

^ This function is the “dag-stobj version” of the function well-f ormed-upl described 
in subsection 5.2. 
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form. For that reason we also test the algorithm on the problem U~^ , where the 
equations of C/„ are processed in reverse order. The following table summarizes 
the results obtained®: 





1 Pref. t/„ 


1 Dag Un 


1 Pref. U~^ 


1 Dag U„ ^ 


1 Quadratic ^ \ 


mm 


Time 


Space 


Time 


Space 


Time 


Space 


Time 


Space 


Time 


1 Space 1 
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376839 
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3 
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49160 
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10 
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22 
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4 
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196654 


18 


11 
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24 
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e 


5 


90 


786444 


72 


12 


e 




1000 


- 


- 


0.2 


151 


- 


- 


- 


- 


15 


195 


5000 


- 


- 


2 


781 


- 


- 


- 


- 


61 


945 



It can be observed that the space complexity is much better in the dag 
implementation than in the applicative implementation in all cases. The time 
performance it is also much better with [/„, and about 25% faster with U~^. 
Note that the definition of the algorithm using mbe is essential for obtaining this 
time performance, since, as we have said, the logical definition of the algorithm 
is impractical for execution. 

The column labeled Dag U~^ reveals that the implemented algorithm has still 
exponential time complexity. The problem is that some operations, like the occur 
check, may traverse terms exponential in size. Nevertheless, the implemented al- 
gorithm is the most often used in practice, since that exponential behavior is not 
usual. Anyway, we have implemented a quadratic version of the dag unification 
algorithm, introducing a few technical modifications to the verified algorithm. 
We also include in the table the tests for this improved version, which it is much 
faster, being able to solve U~^ for n = 5000. For the moment, this quadratic 
implementation is not formally verified. 

7 Conclusions 

We have presented a case study in ACL2, where we verify a unification algorithm 
acting on term dags, implemented using ACL2 single-threaded objects. We urge 
the interested reader to consult the complete development in [11]. The main 
features of this case study are: 

• The formal verification of an executable algorithm that uses efficient data 
structures. 

• The methodology used: from a rule-based specification of the algorithm, we 
prove its more abstract properties. The final properties of the algorithm can 
be seen as an optimization process, using compositional reasoning. 

• The use of the new mbe feature of ACL2, that permits to associate to a func- 
tion some “executable body” that can be different from its “logical body” . 

® Tested on an AMD® 2200XP processor, with 512Mb RAM. The data are obtained 
with the function time of Clisp. The dash denotes that either an output is not 
obtained in reasonable time, or that a stack overflow occurs, e stands for a quantity 
less than 0.01. Numbers bigger than 1 are rounded to the nearest integer. 
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The intuitive idea that algorithms employing more complex data structures 
or more sophisticated control structures require more effort in verification is 
supported by the table of subsection 5.5. These data contrast with the effort 
needed in the verification of the same algorithm using a prefix representation 
of terms [10]. In that work, we needed 19 definitions and 129 theorems, and in 
this case we needed 177 definitions and 703 theorems. Anyway, this additional 
verification effort has resulted in the development of a number of ACL2 files that 
could be used in other formalizations (for example, the theory about directed 
acyclic graphs). 

As for related works, unification algorithms have been the center of several 
formalizations. In particular, formal proofs of the correctness of a unification 
algorithm have been given in LCF [8], Coq [9] and ALF [3]. Although these 
works are related to ours, the logic used is quite different and, more important, 
their main concern is not efficiency or the data structures used. 

Other related work is done by Mehta and Nipkow [7], who have recently de- 
veloped in Isabelle/HOL a general framework for reasoning about programs that 
use pointers. As a non-trivial case study, they present a proof of the correctness 
of the Schorr- Waite graph marking algorithm. This work is more general than 
ours, since all the reasoning about pointers that we do is especifically devoted 
to the results needed by the algorithm. Moreover, the logics used are different: 
in [7], a Hoare logic for pointer programs is embedded in Isabelle/HOL, whereas 
we are using the ACL2 logic for reasoning about ACL2 functions that can be 
directly executed in any compliant Common Lisp. Nevertheless, some of the 
techniques used in [7] are similar to ours: for example, what they call abstrac- 
tion (mapping low level structures in the heap to higher level concepts) is similar 
to what we do when we first reason about the main properties of the algorithm 
using the prefix representation of terms (a higher level representation) and then 
we translate them to the algorithm that uses dags (a lower level representation). 

As for further work, we already pointed out at the end of subsection 6 that 
we can introduce some technical improvements in order to make the verified 
algorithm run in quadratic time. We also plan to verify this improved algorithm. 

Finally, note that although our main concern is an efficient and formally ver- 
ified algorithm, we do not prove theorems about the efficiency of the algorithm. 
Although reasoning about complexity of algorithms in the ACL2 logic is (in 
principle) possible, we think that it could be much more difficult than reasoning 
about the correctness of the algorithm, mainly due to the need of formalizing 
the “big-0 notation” (and its asymptotic character) in the ACL2 logic. 
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Abstract. The input to backwards analysis is a program together with 
properties that are required to hold at given program points. The purpose 
of the analysis is to derive initial goals or pre-conditions that guarantee 
that, when the program is executed, the given properties hold. The so- 
lution for logic programs presented here is based on a transformation of 
the input program, which makes explicit the dependencies of the given 
program points on the initial goals. The transformation is derived from 
the resultants semantics of logic programs. The transformed program 
is then analysed using a standard abstract interpretation. The required 
pre-conditions on initial goals can be deduced from the analysis results 
without a further fixpoint computation. For the modes backwards anal- 
ysis problem, this approach gives the same results as previous work, but 
requires only a standard abstract interpretation framework and no spe- 
cial properties of the abstract domain. 



1 Introduction 

The input to backwards analysis is a program together with properties that are 
required to hold at given program points. The purpose of the analysis is to derive 
initial goals or pre-conditions that guarantee that, when the program is executed, 
the given properties hold. Discussion of the motivation for backwards analysis 
is given by King and Lu [KL02] and Genaim and Godish [GGOl]. For example, 
in a logic program, it is useful to know which instantiation modes of goals will 
definitely not produce run-time instantiation errors caused by calls to built-in 
predicates with insufficiently instantiated arguments [KL02], and which goals 
are sufficiently instantiated to ensure termination [GGOl]. By contrast, program 
analysis frameworks usually start with given goals, and derive properties that 
hold at various program points, when those goals are executed. 

An essential aspect of static analysis using abstractions or approximations is 
that the analysis results are safe. Backwards analysis algorithms have distinctive 
characteristics in this regard. The final result, namely (a description of) the set 
of initial goals that guarantee the establishment of the given properties, should 
be an under approximation of the actual set of goals that satisfy the require- 
ments. Analyses usually yield an over approximation, this has led investigators 
to develop special abstract interpretations that give an under approximation. 
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In this paper we develop a method for using standard abstraction and over- 
approximation techniques, and still obtain valid results for backwards analysis. 
This is achieved by analysing not the original program, but rather a transformed 
program that makes explicit the dependencies between the given properties and 
initial goals. 

The method is presented in terms of (constraint) logic programs. The es- 
sential idea is to transform a given program P into another program (or rather 
meta-program) whose semantics is a dependency relation (A,B), where B is a 
call at some specified program point, and A is an atomic goal for P. Analysis 
of this transformed program yields an over-approximation of the set of depen- 
dencies between A and B, which can then be examined to find goals A that 
guarantee some required property of B. 



1.1 Making Derivations Observable 

The transformation to be presented in Section 2 makes explicit the dependen- 
cies of program points on initial goals. The transformation can be viewed as 
the implementation of a more expressive semantics than usual. Standard se- 
mantics (such as least Herbrand models, c-semantics, s-semantics, call and suc- 
cess patterns for atomic goals, and so on) do not record explicitly the relation- 
ship between initial goals and specific program points. The resultants semantics 
[GLM96,GG94] provides a sufficiently expressive framework. 



Resultants Semantics. A resultant is a formula Qi ^ Q 2 where Qi,Q 2 are 
conjunctions of atoms^. If Qi is an atom the resultant is a clause. Variables 
occurring in Q 2 but not in Qi are implicitly existentially quantified. All other 
variables are free in the resultant. 

Definition 1. Ol{P) 

Given a definite program P, the resultants semantics Ol{P) is the set of all 
resultants^ p{X)9 ^ R such that p{X) is a “most general” atom (that is, an 
atom of the form p{x\, . . . , Xn) where x\, . . . ,Xn are distinct variables) for some 
predicate in P, and ^ p{X), R is an SLD- derivation (with a computation 

rule selecting the leftmost atom) of PU{^ p(-^)} with computed answer 9. Such 
a resultant represents a partial computation of the goal p{X). We include the 
zero-length derivations of form p{X) <—p{X). 

From here on the leftmost computation rule is assumed and the subscript L in 
Ol{P) is omitted. There is also a fixpoint definition of 0{P); abstract interpre- 
tation of the resultants and related semantics was considered in [GLMOl]. 

Other standard semantics can be derived as abstractions of 0{P). The subset 
of elements p{X)9 ^ R G 0{P) where R = true is isomorphic to the s-semantics 

^ Standard terminology and notation for logic programming is used [Llo87]. 

^ Strictly speaking Ol{P) contains equivalence classes of resultants with respect to 
variable renaming, rather than resultants themselves. 
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[BGLM94], from which in turn the c-semantics [Cla79] and the least Herbrand 
model [Llo87] can be derived by computing all instances and ground instances 
respectively. Calls generated by a given goal can also be derived from 0{P). The 
set of calls that arise from a given atomic goal in a leftmost SLD derivation is 
given by the set calls(P, A) = {BiO \ H ^ Bi, . . . , B„ € 0(P), mgu(yl, H) = 0}. 
We assume as usual that A is standardised apart from the elements of 0{P). 

1.2 Backwards Analysis Based on the Resultants Semantics 

The possibility of using the resultants semantics for backwards analysis does not 
seem to have been considered previously. The relation B G calls(P, A) can be 
read backwards; given A is a goal that invokes a call B. 

We can capture the essential information about the dependencies between 
calls and goals using the downwards closure of 0{P), denoted 0^{P). That is, 
0^{P) is 0{P) extended with all the instances obtained by substitutions for free 
variables, which are variables occurring in the resultants’ heads. Then define a 
relation T>, called the goal dependency relation for P. 

P(A,B) = (A^B,...,S„gO+(P)) 

The goal dependency relation for a program is closely related to the binary clause 
semantics of Codish and Taboch [CT99] (but is downwards closed with respect 
to the free variables). 

Proposition 1. Let P he a program, and T> he the goal dependency relation 
for P. Then (i) ifT>{A,B) then B G calls(P, A), and (ii) for all goals A and 
B G calls(P, A), there exists a substitution a such that T>{Aa,B). 

Proof, (i). If T>{A,B) then 0{P) contains A' ^ such that A ^ 

B, . . . , Bn is an instance obtained by a substitution, say 6, for the variables 
in A'. Hence mgu(A, A') = 0 and B = B[0, and so B G calls(P, A) (ii) If 
B G calls(P, A) then 0(P) contains A! G- B[, . . . , B'n, mgu(A, A') = a and 
B = B[a. The instance Act ^ B, , B'nCr is thus contained in the downwards 
closure 0^{P) and hence V{Aa,B) holds. 

Definition 2. Let P he a program and T> he the goal dependency relation for P. 
Let 0 and L> he properties of atoms; that is, for every atom A, 0(A) and 'T(A) 
are either true or false. We say that a call-dependency 0 ^ <P follows from T> 
if there does not exist T>(A, B) such that 0(A) A ~'<P(B). 

Definition 3. A property 0 is called downwards closed if, whenever 0(A) holds, 
0(Aip) holds for all substitutions {p. 

Proposition 2. Let P he a program, and T> he the goal dependency relation for 
P. Suppose 0 ^ <P follows from T>, and that 0 is a downwards closed property. 
Then for all goals A, and B G calls(P, A), 0(A) -G d>(B). 

Proof. Let A be a goal, such that 0(A) holds. For all B G calls(P, A), we must 
establish that d>(B) holds. For each such B there exists some instance Act such 
that V(Aa,B) by Proposition 1. 6 >(Act) holds since 0 is a downwards closed 
property. Hence 'P(B) holds since 0 ^ T> follows from V. 
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Proposition 2 establishes that we can use the goal dependency relation of a 
program in order to establish dependencies between goals and calls, provided 
that the properties on goals are downwards closed. The next proposition shows 
that we can use over-approximations of the goal dependency relation to deduce 
dependencies. 

Proposition 3. Let S be a goal dependency relation and let S' he a relation 
including S. Then, if the call- dependency 0 ^ follows from S' , it also follows 
from S. 

Proof. Suppose that 6> — >■ <? follows from S' . Then there does not exist T){A, B) G 
S' such that 0{A) A Hence such a pair does not exist in S either, and 

so 0 — ^ follows from S. 

We can also explain how our approach achieves the “under-approximations” of 
the conditions on initial goals discussed earlier. Given a call property suppose 
0 — >■ follows from the goal dependency relation T>. In an over-approximation 
of T>, we will in general be able to establish dependencies 0' — >■ such that 

0' — >■ 0. Put another way, the larger the approximation is, the more chance 
there is of finding a counterexample T>{A, B) such that 0{A) A ~'<P{B) . The 
greater the over-approximation, the more restrictive are the properties 0' for 
which 0' ^ <P can be shown. 

The backwards analysis method can now be summarised in the following way. 
The concrete semantics on which we define properties is the goal dependency 
relation T> for a given program. Given a program P we define a transformed 
program containing a predicate whose logical consequences contain the goal de- 
pendency relation T>. Using abstract interpretation of the transformed program, 
we compute approximations of T>, which can be used to establish dependencies 
between goals and calls, as proved in Propositions 2 and 3. 

We shall also define an even more refined transformed program, whose se- 
mantics is restricted to a subset of the goal dependency relation T>, containing 
tuples V{A,B) where H is a call occurring at one of a specified set of program 
points. 

Basing our approach on a downwards closed semantics allows a straightfor- 
ward approach to implementation, using for example the framework presented 
in [GBS95]. Our analyses are based on the c-semantics [Gla79], which is the set 
of atomic logical consequences of a program. Given a program P, let C{P) be 
the c-semantics of P. As shown in [GBS95], C{P) can be given a least fixpoint 
form. 

2 The Program Transformation 

First, the resultants semantics is formulated as a program transformation. 

2.1 Resultants Semantics by Program Transformation 

A resultant A ^ Q is represented as a meta-predicate TZ{A,Q). Let P be a 
program. For each program clause H G- Di, . . . , (n > 0) in P we produce n 
clauses. 
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TZ{H,{Q,D2, . . . ,Dr,)) ^ TZ{D^,Q) 
n{H,{Q,D3,...,Dr,))^ Di,n{D2,Q) 

'JZ{H, Q) •<— Di, . . . , Dn-i, TZ{Dn, Q) 

For each unit clause H ^ true produce a single clause TZ{H, true) ^ true. Finally, 
for each predicate p we add a clause TZ{p{x),p{x)) where p{x) is a most general 
call to p. 

In the bodies of the clauses for TZ there are calls to the original program 
atoms Di,D 2 and so on, so it is assumed that the clauses for P are included 
in the transformed program. These object program calls could have been writ- 
ten 7?.(Di, true), T^(I ?2 7 true) respectively since A is in the minimal model of the 
program iff there is a ground instance of a resultant A •<— true in the resultants 
semantics of the program. If this modification were made, the transformation cor- 
responds closely to the fixpoint definition of the resultants semantics [GLM96] . 
We denote by Resp the collection of clauses defining the predicate TZ as shown 
above, together with P itself. 

Example 1 . Let P be the “naive reverse” program. The transformed program is 
shown in Figure 1. The meta-predicate TZ is denoted res in the program. 



res(rev( [],[]), true) true, 
res (rev( [X I Xs] , Zs) , (Q, app(Ys , [X] ,Zs) ) ) : - 
res(rev(Xs,Ys) ,Q) . 
res (rev( [X I Xs] ,Zs) , Q) 

rev(Xs,Ys) , res(app(Ys, [X] ,Zs) ,Q) . 
res (app( [] ,Ys ,Ys) .true) true, 
res (app( [X I Xs] , Ys , [X I Zs] ) , Q) 
res (app(Xs , Ys ,Zs) , Q) . 
res (rev(X, Y) ,rev(X, Y) ) true, 
res (app(X, Y.Z) ,app(X, Y.Z) ) true. 



rev( [],[]). 
rev( [X I Xs] ,Zs) : - 
rev(Xs.Ys) , 
app(Ys, [X] ,Zs) . 
app( [] ,Ys,Ys) . 
app([X|Xs] ,Ys, [XlZs]) 
app(Xs,Ys,Zs) . 



Fig. 1. Resp where P is the naive reverse program 



Proposition 4. Let P be a program. Then for all resultants A G € 0'^{P), 
TZ{A,G) GC(Resp). 

Proof. (Outline). A derivation corresponding to a resultant can be represented 
as an AND-OR proof tree. The proof is by induction on the depth of AND-OR 
trees. 

Note that C(Resp) contains more instances of resultants than does 0^{P). 
Specifically, local variables in resultants are also instantiated, as well as head 
variables. The transformed program thus represents an approximation of the 
dependency relation. In practice this is not a loss in precision, since clearly no 
dependencies will be derived between local variables in resultants and head vari- 
ables. 
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2.2 From Resultants to Binary Clauses 

The program above can be modified to yield (the downwards closure of) binary 
clauses [CT99]. Only the first call in the right-hand-side of the resultants is 
recorded, rather than the whole resultant. A resultant Ai <— A 2 in which both 
Ai and A 2 are atoms is called a binary clause. In the binary clause semantics, a 
resultant A ^ i?i , . . . , is abstracted to A ^ i?i . 

The transformed program corresponding to the binary clauses is as follows. 
A meta-predicate ,B(Ai, A 2 ) represents the binary resultant Ai ^ A 2 . 

B{H,Q)^ Di,B{D2,Q). 

B{H,Q) ^ Di, . . . , Dn_i,B{D„,Q). 

As before, we add a clause B{p{x),p{x)) for each predicate p where p{x) is a 
most general atom for p. Note that a unit clause in P produces no clauses for B. 
Let Binp be the transformed program consisting of P together with the clauses 
defining the predicate B as shown above. 

Example 2. Let P be the “naive reverse” program. The transformed program is 
shown in Figure 2. The meta-predicate B is denoted bin in the program. 



bin(rev( [X I Xs] ,Zs) , Q) 
bin(rev(Xs,Ys) ,Q) . 
bin(rev( [X I Xs] ,Zs) , Q) 

rev(Xs,Ys) , bin(app(Ys, [X] ,Zs) ,Q) . 
bin(app( [X I Xs] , Ys , [X I Zs] ) , Q) 
bin(app(Xs , Ys ,Zs) , Q) . 
bin(rev(X,Y) ,rev(X,Y) ) true. 
bin(app(X,Y,Z) ,app(X,Y,Z) ) true. 



rev( [],[]). 
rev( [X I Xs] , Zs) : - 
rev(Xs , Ys) , 
app(Ys , [X] , Zs) . 
app( [] ,Ys,Ys) . 
app( [XiXs] ,Ys, [XlZs] ) 
app(Xs,Ys,Zs) . 



Fig. 2. Binp where P is the naive reverse program 



Proposition 5. Let P he a program. Then for all resultants A ^ i?i, . . . , G 
0+{P), B{A,Bi) GC(Binp). 

C(Binp) is an over approximation of the goal dependency relation for P. As 
was the case for the resultants program Resp, the downwards closure of local 
variables is included in the relation B in C(Binp). 

2.3 Transforming with Respect to Program Points 

Next, a further simplification is made, when calls at specified program points are 
to be observed, rather than all calls. We may if required observe only a specific 
argument of a call at some program point. A meta-predicate Dep(Ai,A 2 ) is 
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defined, whose meaning is that there is a clause Ai <— A 2 in the binary clause 
semantics, and A 2 is a call, or some argument of a call, at one of the specified 
program points to be observed. 

Let H Bi, ... ,Bj, , Bn be a clause in a program P. Suppose that we 
wish to observe calls to Bj in this clause body, and determine some property 
of initial goals which establish some property of Bj. In the semantics, only the 
binary clauses of the form A ^ Bj are to be observed: no other calls other than 
those to Bj need be recorded. 

To achieve this, we simply modify the binary clause transformation shown 
above. Specifically, instead of the clauses of form B{p{x) , p{x)) , we create base 
case clauses for the given program points. 

For instance, for the clause H ^ Di, . . . , Dj, . . . , Dn with one point Dj to 
be observed, the following clauses for Dep are generated. 

Dep(iL, Dj) <— Di . . . , Dj—i Dep(iL, Q) ■(— Dep(Z?i, Q). 

Dep(iL, Q) Di, Dep(L>2, Q). 

Dep{H, Q) ^ Di,..., Dn-i, Dep(D„, Q). 

For each body atom to be observed, we add one clause similar to the one for Dj 
above. We can see that the only atoms that can appear in the second argument 
of Dep are instances of Dj. Denote by Depp the transformed program consisting 
of P together with the clauses defining Dep as shown above. 

Proposition 6. Let P he a program, and {Dj .^ , ■ • • , Dj,, } be a set of body atoms 
from clauses in P. Let Depp be the transformed program consisting of P to- 
gether with the clauses defining Dep as shown above. Then for all resultants 
A Dj ., . . . G 0+(P), where Dj, is an instance of one of the specified atoms, 
Dep{A,Djf) eC(Depp). 

The transformation can be refined (with respect to computational efficiency) 
by having a separate Dep predicate corresponding to each predicate in P. That 
is, each occurrence of Dep(p(t),Q) in the transformed program is replaced by 
Depp(t,g). 

The transformation can be varied by observing in the second argument of 
Dep not the actual call, but simply one or more variables from the call. This is 
illustrated in the next example. 

Example 3. Let P be the “naive reverse” program. Suppose the call that we wish 
to observe is app(Ys, [X] ,Zs) in the recursive clause for rev as shown in Fig- 
ure 3. For example, we suppose that we require that integer (X) holds whenever 
this call is encountered. We need observe only the variable X in app (Ys , [X] , Zs) . 
However, the transformation is independent of the actual property. The trans- 
formed program, shown in Figure 3, consists of P together with the clauses defin- 
ing drev/2 and dapp/3 (representing the meta-predicates Dep,,g„ and Dep^pp). 
In place of the call app(Ys, [X] ,Zs) in the final argument, we observe only the 
variable X. 

Next, we apply standard static analysis techniques to the transformed program. 
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drev([X|Xs] ,Zs,X) 
rev(Xs , Ys) . 
drev( [X I Xs] ,Zs ,Q) 
drev(Xs,Ys,Q) . 
drev( [X I Xs] ,Zs , Q) 

rev(Xs,Ys), dapp(Ys , [X] , Zs , Q) . 
dapp([X|Xs] ,Ys, [XlZs] ,Q) 
dappCXs , Ys , Zs , Q) . 



rev( [],[]). 
rev( [X I Xs] ,Zs) : - 

rev(XSjYs) ,app(Ys, [X] ,Zs) . 
app( [] ,Ys,Ys) . 
app([XlXs] ,Ys, [X|Zs]) 
app(Xs,Ys,Zs) . 



Fig. 3. Transformed Naive Reverse Program for Backwards Analysis 



2.4 Analysis of the Transformed Programs 

The transformed program can be input to an abstract interpretation framework. 
In the experiments carried out so far, analysis was based on the c-semantics 
abstracted using pre-interpretations [GBS95] . A pre-interpretation is a mapping 
from terms into a (finite) domain D, defined by a pre-interpretation function 
J. For each n-ary function symbol /, J contains a function I?" — >■ D, writ- 
ten J(/(c?i, . . . , dn)) = d for di, . . . , dn, d € D. A mapping a is defined induc- 
tively as a{c) = d where J(c) = d, for 0-ary functions c, and . . . ,tn)) = 

J(/(a(ti), . . . ,a{tn))) for terms with functions of arity greater than 0. An ab- 
stract “domain program” is generated by abstract compilation, in the style in- 
troduced by Codish and Demoen [CD93]. A bottom-up analysis of the domain 
program yields its c-semantics. Let P be a program and C(P) its minimal model, 
which is identical to the c-semantics in this case. Let P'^ be the abstract domain 
program for some pre-interpretation J . The safety result is that for all atoms 
p(ti, . . . , t„) G C(P), p(a(ti), . . . , a(t„)) G C(P-^). 



Example 4- We analyse the above example where we wish to establish the prop- 
erty app(Ys, [X] ,Zs) GGinteger (X) , for the occurrence of app(Ys, [X] ,Zs) in 
the recursive clause for rev/2. A simple type domain could be used, consist- 
ing of the types int, listint, other. We construct an abstract “domain program” 
as described in [GBS95], based on the pre-interpretation constructed from the 
program’s function symbols and the given types. 

[] — !■ listint [int | other] — ^ other [other | other] — !■ other 

[listint I other] — s- other [int | int] — > other [listint | int] — other 

[other I int] — s- other [int | listint] — s- listint [listint | listint] — ^ other 

[other I listint] — s- other 

The pre-interpretation is encoded as a predicate — >-/2 corresponding to the 
pre-interpretation, that is, for each mapping /(di, . . . , d„) — >■ d in the pre- 
interpretation, we write an atomic clause f (di, . . . , d„) — >■ d : —true. The domain 
program is shown in Figure 4. Its least model over the pre-interpretation for the 
domain of simple types is shown in Figure 5. 
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rev(Xl,X2) 

[]->Xl, []->X2. 
rev(Xl,X2) 

rev(X3,X4) ,app(X4,X5,X2) , 

[X6 I X3] --i>Xl , [] ->X7 , [X6 I X7] ->X5 . 
app(Xl,X2,X2) 

[]-7Xl. 

app(Xl,X2,X3) 

app(X4,X2,X5) , [X6|X4]->X1, [X6 I X5] -S-X3 . 
drev(Xl,X2,X3) 

rev(X4,X5) , [X3 I X4] -)>X1 . 
drev(Xl,X2,X3) 

rev(X4,X5) ,dapp(X5,X6,X2,X3) , 

[X7 I X4] ->X1 , [] -^X8 , [X7 I X8] ->X6 . 
drev(Xl,X2,X3) 

drev(X4,X5,X3) , [X6|X4]->X1. 
dapp(Xl,X2,X3,X4) 

dapp (X5 , X2 , X6 , X4) , [X7 I X5] ->X1 , [X7 I X6] ->X3 . 

Fig. 4. Domain Program for Backwards Analysis of Naive Reverse 

app(listint,Xl ,X1) revCIistint, listint) drevCIistint ,X1 , int) 

appCIistint, int, other) rev (other, other) drev(other,Xl , int) 

app (other, other, other) dr ev (other, XI , listint) 

app (other, int, other) dr ev (other, X, other) 

app (other, listint , other) 

Fig. 5. Least model of program in Figure 4, over domain of simple types 



2.5 Interpretation of the Analysis Result 

Examining the results in Figure 5, we see a number of abstract facts for drev. 
(There are no results for dapp derived since no call to app affects the given 
program point.) The results show that whenever rev/2 is called with its first ar- 
gument a list of integers, then X is an integer at the given program point. This is 
indicated by the fact that drev(listint, XI, int) is in the model of the abstract pro- 
gram, and there are no other tuples drev(listint, XI, Y) where Y yf int. By contrast, 
there is a tuple drev(other, XI, int) but there is also a tuple drev(other, XI, listint), 
so although goals of the form rev (other, Y) might establish the property, they 
are not guaranteed to establish it. 

In terms of the discussion in Section 1.2, the goal dependency 0 ^ <P follows 
from the abstract relation, where 0(rev(X, Y)) is true if X is a list of integers, 
and <?(app(Ys, [X], Zs)) is true is this call arises from the specified program point, 
and X is an integer. 

Example 5. Let P be the quicksort program, shown in Figure 6. Backwards anal- 
ysis was considered for this program in [KL02]. Suppose we wish to check the 
calls to the built-in predicates > and <. The intention is that these predicates 
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dqsort ( [X I Xs] , Ys ,Zs ,Q) 

dpartition(Xs,X,Us,Vs,Q) . 
dqsort ( [X I Xs] ,Ys ,Zs ,Q) 
partition(Xs,X,Us,Vs) , 
dqsort (Us, Ys, [X|Ws] ,Q) . 
dqsort ( [X I Xs] ,Ys ,Zs ,Q) 
partition(Xs,X,Us,Vs) , 
qsort (Us , Ys , [X I Ws] ) , 
dqsort (Us, Ys, [X|Ws] ,Q) . 
dpartition( [X I Xs] , Z, Ys , [X I Zs] ,X > Z) . 
dpartition( [X I Xs] , Z, Ys , [X I Zs] , Q) : - 
X > Z, dpartition(Xs,Z,Ys,Zs,Q) . 
dpartition( [X I Xs] , Z, [X I Ys] ,Zs ,X<Z) . 
dpartition( [X I Xs] , Z, [X I Ys] ,Zs , Q) : - 
X < Z, dpartition(Xs,Z,Ys,Zs,Q) . 

Fig. 6. Transformed Quicksort Program for Backwards Analysis 

require their argument to be ground when called in order to prevent run-time 
instantiation errors. The transformed quicksort program is included in Figure 6. 

2.6 Analysis of Quicksort 

We perform groundness analysis on the program in Figure 6. A pre-interpretation 
over the domain elements g and ng (standing for ground and non-ground) is 
constructed. This is equivalent to the Pos boolean domain. 

D — ^ g [g I g] — ^ g [g I ng] — ^ ng [ng | g] — ^ ng [ng | ng] — ^ ng 

After generating the domain program, the least model is computed and is shown 
in Figure 7. (When computing the minimal model we assign the success modes 
g>g and g<g to the built-ins). 

Examining the results via the relation dqsort, we see that the only calls to 
qsort (X,Y,Z) that guarantee that the required groundness properties g>g and 
g<g are those in which X is ground. The arguments Y and Z are completely inde- 
pendent of the property. For dpartition, note that a variable XI occurs in both 
the final argument of dpartition and in the second argument of partition. 
This variable can be instantiated by g or ng. Thus the second argument of 
partition has to be ground to establish g>g and g<g. In addition, the argu- 
ments of > and < are ground if either the first argument of partition or the 
third and fourth are ground. These are the same results reported by King and 
Lu [KL02], summarised as X 2 A (Ai V (A3 A A4)) in the notation of Pos, where 
Ai, . . . , A4 are the arguments of partition. 

2.7 Computing the Goal Conditions 

For examples such as the ones discussed above, the required properties of the 
input goals that guarantee the observed property were derived informally by 
examining the abstract tuples. We now explain how to do this systematically. 



qsort ( [] , Ys , Ys) . 
qsort ( [X I Xs] , Ys , Zs) 

partition(Xs,X,Us,Vs) , 
qsort (Us , Ys , [X I Ws] ) , 
qsort(Vs,Ws,Zs) . 
partition( [] ,Z, [],[]) . 
partition( [X I Xs] ,Z , Ys , [X I Zs] ) 

X > Z, partition(Xs ,Z,Ys ,Zs) . 
partition( [X I Xs] ,Z , [X I Ys] , Zs) 

X < Z, partition(Xs ,Z, Ys ,Zs) . 
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qsort(g,Xl,Xl) 

qsort(ng,ng,g) 

qsort(ng,ng,ng) 



partition(g,Xl,g,g) 



dpartition(ng,Xl,ng,X2,g<Xl) 

dpartition(ng,Xl,g,X2,g<Xl) 

dpartition(ng,Xl,ng,X2,ng<Xl) 

dpartition(g,Xl,ng,X2,g<Xl) 

dpartition(g,Xl,g,X2,g<Xl) 

dpartition(ng,Xl,X2,ng,g>Xl) 

dpartition(ng,Xl,X2,g,g>Xl) 

dpartition(ng,Xl,X2,ng,ng>Xl) 

dpartition(g,Xl,X2,ng,g>Xl) 

dpartition(g,Xl,X2,g,g>Xl) 



dqsort(ng,Xl,X2,ng>ng) 

dqsort(ng,Xl,X2,ng>g) 

dqsort(ng,Xl,X2,g>ng) 

dqsort(ng,Xl,X2,ng<ng) 

dqsort(ng,Xl,X2,ng<g) 

dqsort(ng,Xl,X2,g<ng) 

dqsort(g,Xl,X2,g>g) 

dqsort(g,Xl,X2,g<g) 

dqsort(ng,Xl,X2,g>g) 

dqsort(ng,Xl,X2,g<g) 



Fig. 7. Least model of program in Figure 6, over groundness domain 



Let Dep(^, B) be the abstract dependency relation returned by the analysis, 
which is a finite set of tuples. Let <P be the property required in the call; that is, we 
seek calls B where ^{B) is true. Consider the set S = {A \ Dep(^, B) A<P{B)} . S is 
the set of calls that possibly establishes ^{B). Now consider candidate properties 
0 that hold for all elements of S. For each such property, check whether there 
exists Dep(A, B) such that 0{A) and ~'<P{B). If there is, the candidate property 
is eliminated. For all other candidate properties, we have established that 0 — 
follows from the abstract dependency relation. 

We illustrate this process for the quicksort example. Consider the relation 
dqsort shown in Figure 7. The required property is that <P{g > g) and <P{g < g) 
are true and <P is false for all other arguments of > and <. The tuples in the 
abstract dqsort relation in which (p holds are the following. 

dqsort(g, XI, X2, g>g) 
dqsort(g, XI, X2, g<g) 
dqsort(ng, XI, X2, g>g) 
dqsort(ng, XI, X2, g<g) 

A candidate property is then that the first argument of qsort can be either 
g or ng, to establish the required property. However, we can search the relation 
to find a counterexample to the candidate property that the first argument is 
ng, such as dqsort(ng,Xl,X2,ng<g). However we can find no counterexample 
to the property that the first argument is g. Hence we have established that 
qsort(g,Xl,X2) -A <P. 



2.8 The Relative Pseudo-complement 

Domains which possess a relative pseudo-complement allow a more direct 
method. Giacobazzi and Scozzari [GS98] identified a property of abstract do- 
mains that allows analyses to be reversible. This property is central to the ap- 
proach of King and Lu [KL02,KL03]. The key property is that the domain pos- 
sesses a relative pseudo- complement operator. We quote the definition as given 
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by King and Lu. Let D be an abstract domain with meet and join operations 
n and U. Let di,d ,2 be elements of D. The pseudo-complement of di relative to 
^ 2 , denoted di =k ^2 is the greatest element whose meet with di is less than d 2 - 
that is, c?i =k ^2 = Lljd € D \ dr\ di Q ^ 2 }- 

To take Example 5 again, treat g and ng as true and false respectively. The 
set of abstract tuples for say, dpartition in Figure 7, can be rewritten as the 
following boolean expression, in the domain Pos, which possesses a relative 
pseudo-complement operation (here q{X,Y) means X >Y A X <Y) . 

dpartition(Xi, X2, X3, AT4, g(X5, Xe)) = 

(X 2 O Xg) A ((Xi A X 3 A X 5 ) V (Xi A X 3 A X 5 ) V (Xi A X 3 A XgjV 

{X_i AXjA Xj) V {Xi AXjA X5) V {Xi A X 4 A X^) V {Xi A X4 A XgjV 

(Xi AXiA X5) V (Ail AX4A X5) V {Xi A X 4 A X^)) 

The pseudo-complement of the above boolean expression relative to the de- 
sired property X^ A Xq gives X2 A {Xi V (X 3 A ^ 4 )), which is equivalent to the 
result derived in Example 5, and the same as that reported by King and Lu 
[KL02] for this predicate. 

3 Related Work 

The most closely related work is that of King and Lu [KL02,KL03], who de- 
scribe a method for backwards analysis of logic programs, and report results 
for the domain of ground and non-ground modes. Their results have all been 
reproduced by the technique shown above, but a formal proof of equivalence 
has not yet been constructed. Their approach requires the construction of an 
abstract interpretation which under-approximates the concrete semantics. This 
requires the definition of a universal projection operator, and requires a con- 
densing domain possessing a relative pseudo-complement operator. The fixpoint 
computation uses a greatest fixpoint rather than the standard least fixpoint. Our 
approach appears to be more flexible in the sense that a wide variety of domains 
can be used for the analysis, not only condensing domains. The relative pseudo- 
complement, if it exists, can be used in our approach to extract the result from 
the abstract program, but is not essential. 

Mesnard et al. [Mes96,MN01] have also performed termination inference, 
which is a form of backwards analysis. Their approach uses a greatest fixpoint, 
and in this respect seems to align more with the approach of King and Lu. 

The binary clause semantics of Codish and Taboch [CT99] was used to make 
loops observable, by deriving an explicit relationship between a calls and its 
successor calls. The transformation presented here can be targeted to observe any 
program points of interest, not only loops, but the spirit of the approach is the 
same. In later work based on binary clause semantics, Genaim and Codish [GCOl] 
perform termination inference which involves backwards analysis. However, they 
use the framework of King and Lu for the backwards analysis, rather than the 
binary clause semantics. 

Binary clause semantics is derived from the more general and expressive re- 
sultants semantics [GLM96,GG94]. We do not know of any implemented ap- 
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plications of resultants semantics, apart from the present work and that of 
[CT99,GC01], nor any previous suggestion that resultants semantics could form 
the basis for backwards analysis. 

The approach of transforming programs to realise non-standard semantics 
is also followed in the query-answer transformations, which include magic-set 
transformations and its relations [DR94,BMSU86]. There, the aim is to simu- 
late a top-down goal-directed computation, in a bottom-up semantic framework. 
A related approach is advocated by Codish and Spndergaard [CS02]. Different 
semantics for logic programs can be represented by meta-interpreters, which 
are also written as logic programs. Codish and Genaim’s implementation of the 
binary semantics [GCOl] follows this style. 

4 Conclusion 

A method for backwards analysis of logic programs has been presented. Given 
a program, and one or more specified body calls, a program transformation is 
performed. In the transformed program, the dependencies between the selected 
calls and initial goals is made explicit. Analysis of the transformed program 
using abstract interpretation yields an over-approximation of the dependency 
relation, and it was proved that dependencies could safely be derived from the 
approximation . 

In contrast to previous work on backwards analysis, our approach requires no 
special properties of the abstract domain, nor any non-standard operations such 
as universal projection, or a greatest fixpoint computation. This is put forward 
as an advantage of our approach, since implementations can be based on existing 
abstract interpretation tools. 

Experimental results carried out so far indicate that this method is of similar 
complexity to other reported work on backwards analysis, and gives equivalent 
precision at least over the Boolean domain Pos. A detailed analytical comparison 
is difficult due to the great differences between the two approaches. It is indeed 
quite surprising that two such different algorithms yield the same results in 
experiments carried out so far. 

Our use of downwards closed semantics does not seem to be essential to our 
general approach, but does allow a simpler analysis and implementation. 

Acknowledgements. Thanks to Andy King and Mike Godish for introduction 
to, and discussions on backwards analysis, and to Maurice Bruynooghe and 
the LOPSTR’03 referees for valuable comments on an earlier draft. Roberto 
Giacobazzi, Samir Genaim and Maurizio Gabbrielli also provided useful feedback 
on the version appearing in the LOPSTR’03 Pre-proceedings. This research is 
supported in part by the IT-University of Gopenhagen. 
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Binding-Time Analysis (BTA) is one of the compile-time program analyses which 
is a general framework for program optimization and program generation [1]. 
The task of BTA is to divide a source program into two parts according to a 
given binding-time specification [2]. A binding-time specification gives informa- 
tion about availability of data: static data are available at compile-time while 
dynamic data are available at run time. BTA determines, from a binding-time 
specification of the input, on which parts computation can take place by propa- 
gating information on static data. Partial evaluators specialize the program for 
the static data by using the information from BTA to generate a more efficient 
program than the original. 

By now several algorithms for BTA has been developed, such as abstract in- 
terpretation [3], type inference [4], constraint solving [5] or type based search [6]. 
Looking at the type directed searching approach proposed by Tim Sheard and 
Nathan Linger [6], we found two unclear points. First, it is not obvious how 
the algorithm can cut off the searching space, and the precise running time is 
left unestimated. The second concerns the accuracy of the solution. The result 
obtained by the algorithm is good, but may not be the best. These two kinds of 
uncertainty are due to the existence of heuristics. 

We developed a new algorithm for BTA which makes use of an established 
method of program transformation, the optimization theorem for the maximum 
marking problem [7, 8] . This is a technique to derive an efficient program based 
on dynamic programming. Since it formally gives the estimation of computation 
complexity and guarantees optimality of solutions with respect to given weight 
functions, the obtained BTA naturally inherits these characteristics. 

The main contribution of our algorithm is to avoid iterations in BTA. Finite- 
ness of binding-time enables us to compute all possible binding-time annota- 
tions by only one traversal over the given program. The naive algorithm in this 
approach obviously requires a large table to memoize intermediate results; we 
address the problem by applying the optimization theorem. The theorem dras- 
tically reduces the intermediate table if a problem is in a suitable form in which 
we are to formalize the original BTA problem. 
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Moreover, our algorithm computes the optimal solution under given measure- 
ments of optimality. Generally an expression has multiple ways of binding-time 
annotations that conform to given binding-time specification. In such cases we 
want to select the optimal one as the result. Though the measurement of optimal- 
ity is up to users, a result which computes more parts in static is normally better 
than the others. Our algorithm allows users to define their own measurement, 
and it derives the optimal solution under the measurement. 

It is true that the derived BTA algorithm is rather traditional one, namely 
a simple monovariant algorithm which gives one binding-time specification for 
each function, but the proposed framework is of much use: Since marks, pred- 
icates and weight functions are parameterized in our algorithm, we can devise 
new strategies for BTA and their implementations follow directly. Furthermore, 
the optimization theorem guarantees that the all algorithms derived via our 
framework run in linear time with respect to the size of the analyzed program. 
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Termination is well-known to be one of the important aspects of program cor- 
rectness. Logic programming provides a framework with a strong theoretical 
basis for tackling this problem. However, due to the declarative formulation 
of programs, the danger of non-termination may increase. As a result, termina- 
tion analysis received considerable attention in logic programming. Recently, the 
study of termination of numerical programs led to the emerging of the adorn- 
ing technique [7]. This technique implements the well-known “divide et impera” 
strategy by distinguishing between different subsets of values for variables, and 
deriving termination proofs based on these subsets. In this paper we generalise 
this technique and discuss its applicability to the domain of terms (the Herbrand 
domain) . 

A set of adornments is derived from the program itself. As a basis for a 
set of adornments one can use types [1], sets of integers [7]. Given a program 
and a set of adornments, the program can be transformed such that a predicate 
p“ in the transformed program is called if and only if the corresponding 
predicate p is called in the original program P and the arguments of the call are 
in the segment a. One can show that under certain conditions this transformation 
preserves termination. In this way (implicit) information on the domain is made 
explicit in the transformed program. It should be observed, that instead of one 
level mapping required for P that is supposed to decrease along all possible 
computations, in order to prove termination of one can find a number of 
potentially less sophisticated different level mappings for each one of the “cases” . 
In the examples we have considered, such level-mappings can be constructed 
automatically, and thus, they play a key role in automation of the approach. It 
should be noted that the transformation we performed can be seen as a form of 
multiple specialisation [8]. After the transformation step is performed, existing 
termination analysers can be applied to infer termination of the transformed 
program. Since the transformation above preserved termination, termination of 
the original program is implied as well. 

The contributions of this work are twofold. First of all, it leads us to an 
entirely new understanding of the relationship between partial deduction and 
termination analysis. While so far termination has been brought together with 
partial deduction only in the context of terminating the deduction process [2, 
5], i.e., of using termination analysis techniques for program specialisation, we 
suggest a complementary approach of using program specialisation techniques 
for termination analysis. On a practical note, this relationship implies that tools 
like ECCE [4] or Mixtus [6] can be used to generate specialised programs to be 
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fed to termination analysers. Alternatively, one can design specialisation tech- 
niques specifically for termination analysis. Our adornments methodology can 
be considered as an example of such technique. The main advantage of our 
results is the uniform approach to different kinds of computations: numerical 
(integer and floating-point) and symbolic (unification-based and interargument 
relations-based) . 

The practical importance of the transformation can be illustrated by observ- 
ing that for such examples as dist [3] , none of the termination analysers available 
is powerful enough to prove termination of the original program, while all of them 
succeed in proving termination of the transformed one. 
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Abstract. In this paper we formally state and prove theorems charac- 
terizing when a function can be constructively reformulated using the 
recursion operators fold and unfold, i.e. given a function h, when can a 
function g be constructed such that h = fold g or h — unfold g? These 
results are refinements of the classical characterization of fold and unfold 
given by Gibbons, Hutton and Altenkirch in [6]. The proofs presented 
here have been formalized in Nuprl’s constructive type theory [5] and 
thereby yield program transformations which map a function h (accom- 
panied by the evidence that h satisfies the required conditions), to a 
function g such that h = fold g or, as the case may be, h = unfold g. 



1 Introduction 

Under the proofs-as-programs interpretation, constructive proofs of theorems re- 
lating programs yield “correct-by-construction” program transformations. In this 
paper we formally prove constructive theorems characterizing when a function 
can be formulated using the recursion operators fold and unfold, i.e. given a func- 
tion /i, when does there exist (constructively) a function g such that h = fold g 
or h = unfold gl The proofs have been formalized in Nuprl’s constructive type 
theory [5] and thereby yield program transformations which map a function h 
— accompanied by the evidence that h satisfies the required conditions - to a 
function g such that h = fold g or, as the case may be, h = unfold g. 

The results presented here are refinements of the classical characterization 
of fold / unfold given by Gibbons, Hutton and Altenkirch in [6]. As they remark, 
their characterization is set theoretic and makes essential use of classical logic and 
the Axiom of Choice. A constructive characterization of fold was given by Weber 
in [15] and a counter-example showing that indeed, under the characterization 
given in [6], there are constructive functions h that can be written in the form 
fold g where g is necessarily incomputable. We extend those results here and 

* This work was supported by NSF grant GCR-9985239, a DoD Multidisciplinary 
University Research Initiative (MURI) program administered by the Office of Naval 
Research under grant N00014-01- 1-0765, and by the PhD program Logic in Gomputer 
Science of the German Research Foundation. 
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present a constructive characterization for both fold and unfold. Following [6] 
our results are presented in the context of a category-theoretic framework, also 
formalized in Nuprl. 

In the next section we describe the definitions of the Nuprl formalization of 
category theory required later in the paper resisting elaboration. We do not state 
or prove any theorems in this section. A description of the Nuprl formalization 
of category theory can be found in [15]. In following sections we define catamor- 
phisms and anamorphisms and, relying on their universal property, give formal 
Nuprl definitions of fold and unfold. We present the statements of the theorems 
which classically characterize fold and unfold from [6]. It turns out that one direc- 
tion of the classical theorems is constructively provable. For the other direction, 
we refine the conditions on the antecedents to obtain characterizations of fold 
and unfold which hold constructively. The constructive content of the proof of 
these theorems are the desired program transformations. 



2 Category Theory in Nuprl 



The Nuprl type theory and proof system have previously been described in this 
conference [4], a recent and comprehensive reference for Nuprl’s constructive 
type theory is available on-line [1]. In short, Nuprl draws heavily on Martin-L6f 
type theory [12], which uses an open-ended sequence of universes Ui, U2, U3, . . . 
to stratify the concept of type. 

The formal Nuprl definition of the type category (up through universe level 
i) is shown in Fig. 1. This definition follows the standard definition, as found 
in say [10]. In the definition: Obj is the type of objects in the category; A is the 
type of arrows; dom and cod are the functions mapping arrows to their domains 
and codomains; o is the type of the composition operator (which is constrained 
to be defined only on arrows whose domains and codomains align properly and 
is associative); and the final component of the product, id, specifies the function 
which maps objects to arrows preserving the unit law. 



Cat{ 


- def 

1} = 




Obj :Ui 






X 


A:Ui 






X 


dom: 


(A ^ 


Obj) 


X 


cod: 


(A ^ 


Obj) 


X 


0 : fo 


: (g:A 


— >■ f 



A I cod f = dom gl — > 

{h:A| dom h = dom f A cod h 
Vf,g,h:A. cod f = dom g A cod g = dom h => 
(hog) of=ho (gof) 



cod g>) I 



■[id:(p: 0 bj — > {f:A| dom f = p A cod f = pi) I 
Vf:A. (id(cod f)) o f = f A f o (id(dom f)) 



f} 



Fig. 1. Abstraction: category 

For a category C we use selectors C_Dbj , C_Arr, C_dom, C_cod, C_op and 
C_id to refer to the components of C. 
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The analog of the large category of sets in our type theoretic formulation 
is the category of types whose universe level is bounded by some j G N. The 
arrows in this category are triples of the form (A,B,f) where A,BGUi and 
f G A ^ B. The category of types is defined in Fig. 2. 




The well-formedness goal is stated as: large_category{i> E Cat{i’}, i.e. 
it says that the category of types below universe level i inhabits the type category 
at level i + 1. 

A miscellany of defined notions used later in the paper are displayed in Fig. 3. 

def 

C-composable(f ,g) = C_cod f = C_dom g 

Mor[C](p,q) = {f:C_Arr| C_dom f = p A C_cod f = q} 

d@f 

C-initial(p) = Vq:C_0bj. 3!f:C_Arr. C_dom f = p A C_cod f = q 

d@f 

C-terminal(p) = Vq:C_0bj. 3!f:C_Arr. C_dom f = q A C_cod f = p 

Fig. 3. Abstractions: composable, morphism, initial and terminal 

Functors are arrows between categories. A functor from C to T>, where C 
and T> are categories, maps objects in C to objects in T> and arrows in C to 
arrows in T> such that these maps preserve structure, i.e. they are compatible 
with the categories’ domain and codomain operators, preserve identity elements 
and respect composition of arrows. The formal definition is given in Fig. 4. 

dsf 

Functor{i}(C,D) = 

{C:Cat{i}J 
X {D:Cat{i}> 

X 0:(C_0bj ^ D_Dbj) 

X {M:C_Arr — > D_Arr| 

(Vf:C_Arr. D_dom (M f) =0 (C_dom f) 

A D_cod (M f) = D (C_cod f)) 
cA ((Vf:C_Arr. Vg:-[g:C_Arr I C_dom g = C_cod fj 
M (g C_op f) = (M g) D_op (M f)) 

A (Vp:C_0bj. M (C_id p) = D_id (0 p)))} 

def 

F_dom =F.l 



Fig. 4. Abstractions: functor, functor_dom and functor_cod 

Given a category C and a functor F : C ^ C, an algebra over A is a pair 
{A,f), where A is an object and f : FA ^ A is an arrow in C. The formal 
definitions are given in Fig. 5. 
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Algebra (F) = 

p:F_dom_0bj X {f :F_dom_Arr I F_dom_dom f = F_0 p A F_dom_cod f = p} 
Hom(F) = 

A : Algebra(F) 

X B : Algebra (F) 

X {f : F_dom_Arr I (F_dom_dom f = A_obj) cA (F_dom_cod f = B_obj) 

cA (f F_dom_op A_arr = B_arr F_dom_op (F_M f))}- 

dof 

algebra_category (F) =<Algebra(F) , Hom(F) , Ah.h_dom, Ah.h_cod, 

Ah.g.h o_hom[F] g, AA. id_hom [F] (A) > 

Fig. 5. Abstractions: algebra, homomorphism and algebra_category 



A coalgebra is a pair where A! is an object and f \ A! ^ FA! is 

an arrow in C. Thus, coalgebras are algebras over the dual category. The formal 
definitions are given in Fig. 6. 
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cA ((F_M f) 


F_dom_op 
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= B_arr F. 


_dom_op f)} 


coalgebra_category (F) 


= <Coalgebra(F) , Cohom(F) , 


Ah.h_dom, 


Ah.h_cod, 




Ahjg.h 0 


_cohom[F] 


g. 


AA 


id_cohom [F] (A) > 



Fig. 6. Abstractions: coalgebra, cohomomorphism and coalgebra_category 



3 Catamorphisms and Anamorphisms 

Catamorphisms (‘folds’) and anamorphisms (‘unfolds’) can be formalized as cer- 
tain arrows in the category of algebras and in the category of coalgebras, re- 
spectively. Significantly, they serve as a basis for a transformational approach to 
functional programming [3] and a wide variety of transformations, optimizations 
and proof techniques are known for algorithms that are expressed as combina- 
tions of folds and unfolds [14, 2, 8, 7, 9, 15]. 

Catamorphisms are homomorphisms from an initial algebra in the category of 
algebras, anamorphisms are defined as cohomomorphisms to a terminal coalgebra 
in the category of coalgebras. 

An algebra {fJ-F, in) is initial if and only if it is an initial object (see Fig. 3) 
in the category of algebras; that is, for every algebra {A, /), there exists a unique 
homomorphism h : {pF,in) {A,f). A coalgebra {vF,out) is terminal if and 
only if it is a terminal object in the category of coalgebras; i.e., for every coal- 
gebra (A, /), there exists a unique cohomomorphism h : (A, /) — > {vF, out). 

Definition 1 (fold) Suppose C is a eategory, F : C ^ C is a functor and 
{fiF,in) is an initial algebra. Then for every algebra {A,f), fold f is defined 
as the unique homomorphism from {pF, in) to (A, /) . 
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, F(fold/) 

F{fiF) FA 



/j,F >■ A 

^ fold f 



Fig. 7. (fold f)-in = f- F(fold /) 



We say an arrow h is a, catamorphism if and only if it can be written as fold / 
for some arrow /. 

Definition 2 (unfold) Suppose C is a category, F \ C ^ C is a functor and 
{vF,out) is a terminal coalgebra. Then for every coalgebra {A,f), unfold f is 
defined as the unique cohomomorphism from {A, f) to {vF, out). 



unfold / 

A >■ fF 



FA- 



F{uF) 



f(unfold /) 

Fig. 8. F(unfold /) • / = out ■ (unfold /) 



Figure 8 illustrates this situation. We say an arrow h is an anamorphism if and 
only if it can be written as unfold / for some arrow /. These definitions imply 
the following universal properties for fold and unfold [11]. 

Theorem 1 (Universal Property: fold). Let C be a category, F : C ^ C a 

functor and {pF, in) an initial algebra. Furthermore, suppose that {A, f) is an 
algebra and that h : pF —f A. Then 

h = fold f 4=^ h ■ in = f ■ Fh. 

Theorem 2 (Universal Property: unfold). Let C be a category, F : C ^ C 
a functor and {uF, out) a terminal coalgebra. Furthermore, suppose that {A, f) 
is a coalgebra and that h : A ^ vF . Then 

h = unfold f 4=^ Fh ■ f = out ■ h. 

Based on their universal properties, formalize fold and unfold as relations 
(shown in Fig. 9). The well-formedness theorems state that they inhabit P, 
Nuprl’s type of propositions. We remark that h is unique when h = unfold/ 
or h = fold /. 
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h=fold[C,F,I] (f ) = (F_dom_dom h = I_obj) cA (F_dom_cod h = f_obj) 
cA (h F_dom_op I_arr = f_arr F_dom_op (F_M h) ) 

dof 

h=unfold[C,F,T] (f) = (F_dom_dom h = f_obj) cA (F_dom_cod h = T_obj) 
cA ((F_M h) F_dom_op f_arr = T_arr F_dom_op h) 



Fig. 9. Abstractions: fold and unfold 



4 When Is an Arrow a Catamorphism 
or an Anamorphism? 

The universal properties for fold and unfold provide technically complete answers 
to this question. An arrow h : fiF — > A is a catamorphism if and only ii h ■ in = 
f ■ Fh for some arrow / : FA — > A. However, usually only the arrow h is given 
- how would we know if an arrow / exists such that the above equation holds? 
And more importantly, how would we construct / from h? Dually, an arrow 
h : A vF is an anamorphism if and only if Fh ■ f = out ■ h for some arrow 
f : A ^ FA. Again, to show that / exists or methods to construct it are not 
given. 

E. Meijer, M. Fokkinga, and R. Paterson [13] give the following results re- 
garding left and right invertible arrows. 

Definition 3 (Left and Right Invertible) Let C be a category and f an ar- 
row in C. 

1. ) We say f is left-invertible (in C) if and only if there exists an arrow g in C 

such that g • f = id{dom{f)). 

2. ) We say f is right-invertible (in C) if and only if there exists an arrow g in 

C such that f ■ g = id{cod{f)) . 



The corresponding Nuprl abstractions are shown in Fig. 10. Their well- 
formedness theorems simply state that these abstractions are propositions. 



d0f 

left-invertible [C] (f) = 




3g:{g:C_Arr| C-composable(f ,g) } 


g C_op f = C_id (C_dom f) 


dGf 

right-invertible [C] (f) = 




3g:-[g:C_Arr 1 C-composable(g,f)} 


f C_op g = C_id (C_cod f) 



Fig. 10. Abstractions: left_invertible and right_invertible 



The following theorems provide tools to show when / exists. 

Theorem 3. If C is a category, F : C ^ C is a functor with an initial algebra 
(fiF,in), and h : fxF —f A is a left-invertible arrow in C, then, for some arrow 
f : FA^ A, h= foldf. 

Theorem 4. IfC is a category, F : C C is a functor with a terminal coalgebra 
(vF, out ) , and h : A —f vF is a right-invertible arrow in C, then, for some arrow 
f : A^ FA, h= unfold f. 
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The Nuprl theorems formalizing these results are shown in Fig. 11. Proofs in 
Nuprl are created in an interactive fashion. In each proof step, instances of (one 
or more) proof rules are chosen by the user and applied to the current sequent. 
Both theorems above are proved in about 70 steps each. 

VC:Cat-[i}-. VF:Functor{i}(C,C) . 

VI : {I : Algebra(F) I algebra_category(F)-initial(I)J . 

Vh:{h:F_dom_Arr I F_dom_dom h = I_obj} . 
left-invertible [F_dom] (h) ^ (3f : Algebra(F) . h=fold[C,F,I] (f ) ) 
VC:Cat-CiJ. VF:Functor{i}(C,C) 

VT: {T: Coalgebra (F) I coalgebra_category(F)-terminal(T)}- 
Vh:{h:F_dom_Arr I F_dom_cod h = T_obj} 
right-invertible [F_dom] (h) => 3f :Coalgebra(F) . h=unfold[C,F,T] (f) 

Fig. 11. Thms: left_invertible_implies_f old right_invertible_implies_unf old 

Figure 12 shows the extract^ of the proof of right_invertible_implies_ 
unfold. We can clearly see the witness term in Nuprl notation: The witness term 
is given by the coalgebra <F_dom_dom h, (F_M g) F_dom_op (T_arr F_dom_op 
h)>. A similar extract results from the proof of the theorem left_invertible_ 
implies_f old. 

AC,F,T,h.p. 
let <g,_> = p in 

<<F_dom_dom h, (F_M g) F_dom_op (T_arr F_dom_op h)>. Ax, Ax, Ax> 

Fig. 12. Simplified Extract of right_invertible_implies_unf old 



5 Classically Characterizing fold and unfold 

For the special case of the category SET, with sets as objects and functions 
as arrows, J. Gibbons, G. Hutton, and T. Altenkirch [6] proved the following 
theorems characterizing when an arrow is a catamorphism or an anamorphism. 

Theorem 5 (Gibbons, Hutton, Altenkirch: fold). Let F : SET — > SET 

be a functor with an initial algebra {fj.F,in), A be a set, and h : fj.F — > A. Then 
(3g : FA — > A. h= foldg) ker{Fh) C ker{h • in). 

Here, ker /, the kernel of a function / : A — > H, is defined as a binary relation 
on A containing all pairs of elements in A that are mapped to the same element 
in B. It is formalized in Fig. 13. 

We remark here that this theorem of classical set theory is too strong in the 
following sense: there exists a function h such that h is computable and such 
that ker {Fh) C ker{h ■ in) but where g, which exists by Thm. 5, is necessarily 
incomputable [15]. 

The following theorem characterizes the dual unfold. 

^ The extract has been simplified by unfolding definitions, performing /3-reductions 
and a-renaming selected variables to make the code more readable. 
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Theorem 6 (Gibbons, Hutton, Altenkirch: unfold). Let F : SET — > SET 

he a functor with a terminal coalgehra {vF, out) , A he a set, and h : A vF . 

Then {3g : A — > FA. h = unfoldg) img{out ■ h) C img(Fh). 

The image of a function f : A ^ B, img/, is the dual notion to the kernel 
of / (see Fig. 13). 

dsf 

ker[A,B] f ={aa:A X A I f aa.l = f aa.2}- 

Hof 

img[A,B] f ={b:B| 3a:A. b = f a} 

Fig. 13. Abstractions: kernel and image 



6 A Constructive Characterization of fold and unfold 

Translating the statements of Thms. 5 and 6 so that the category SET is replaced 
by the large category of types result in theorems that are constructively provable 
in the (^) direction [15]. However, the (<;=) direction contains the computation- 
ally interesting parts of these theorems; it claims existence for the function g we 
are interested in. 

6.1 Characterizing fold 

Analyzing the proof of Thm. 5 led us to identify additional constraints that 
in fact allow a constructive proof of a modified version of the {<=) direction. 
Before we state these conditions, we must address an issue that is not raised by 
differences between classical and constructive mathematics, but by the inherent 
differences between set theory and type theory. 

Thus far, while considering the constructive interpretation of the classical 
results we have interpreted types mutatis mutandis as sets. Up to this point this 
informal practice has proved harmless, but at this point our naive identification 
of sets and types fails. Consider the analogue of the empty set, i.e. types having 
no inhabitants. Equality on types in Nuprl is not extensional as it is for sets. 
Hence, unlike set theory, where every set containing no elements is identified 
with 0, there is no canonical representative for the empty type; e.g. neither 
Void nor {cc : Z| a: < a;} are inhabited and yet they are distinguished as types. 
The identification of empty sets with the empty set is a crucial step in the {<=) 
direction of the classical proof. 

Here is the statement of the refined theorem (still in terms of the category 
SET) corresponding to the (<;=) part of Thm. 5. 

Theorem 7. Let F : SET — > SET he a functor with an initial algebra {fj,F,in), 
and let A he a set such that we can decide whether A is empty, and h : piF — > A. 
Furthermore, suppose that for every b G FA we can decide whether b = (U/i)(a) 
for some a S F{pF). Then {3g: FA A.h = foldg) -i= ker{Fh) C ker(/i • in). 

Figure 14 shows a type-theoretic formalization of this theorem in Nuprl. 
Dec(P) is used to abbreviate P V — iP. The proof depends on two lemmata. 
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namely that the inclusion of kernels implies the existence of postfactors, and 
that the existence of a function h : —>■ A implies the existence of a function 

g : F A ^ A. We say g : S — > C is a postfactor of f : A ^ B for h : A ^ C if 
and only if h = g ■ f. We will use the notation A ^ B ^ id to mean that there is 
a function inhabiting A ^ B. 

We state and prove the former lemma first. 

VF : Functorfi ’ }(large_category{i} , large_category{i}) . 

VI : {I : Algebra(F) I algebra_category(F)-initial(I)J . 

VA : large_category-[i}-_Obj . Vh:Mor [large_category-[i}-] (I_obj ,A) . 

Dec(A) (Vb:F_D A. Dec(3a:F_0 I_obj . b = (F_M h).2.2 a)) => 

( (3g: Algebra(F) . h=fold[large_category{i},F,I] (g) ) 

ker [F_0 I_obj , large_categoryCiJ_cod (F_M h)] (F_M h).2.2 
C ker[F_D I_obj , large_category{i}_cod (h F_dom_op I_arr)] 

(h F_dom_op I_arr).2.2) 

Fig. 14. Theorem: kernel_inclusion_implies_f old 

Lemma 1. Let f : A ^ B and h : A ^ C . Furthermore, suppose we can decide 
whether C is empty, and for every b £ B we ean decide whether b = /(a) for 
some a € A. Then (3g : B —> C. /i = g • /) 4= (ker / C ker A — > C yf 0). 

Proof. Assume ker / C ker h and B ^ C ^ 

If C = 0, then B = % since B ^ C ^ and A = 0 since f : A ^ B. 
Therefore f = h = id{%), and if we choose g = id{%), clearly g : B ^ C and 
h = g- f. 

If C yf 0, let c be an arbitrary element in C. Let choice : {b G B \ 3a G 
A. b = f{a)} — > A be a function with f{choice{b)) = b for &ffb G {b G B \ 3a G 
A. b = /(a)} For b G B define g{b) G C as follows: If 6 = /(a) for some a G A, 
then g{b) = h{choice{b)) . Otherwise, g{b) = c. 

Now let a G A. Since f{ehoice{f{a))) = f{a) by definition of ehoice, we have 
{ehoice{f {a)) , a) G kerf C ker h. Hence g{f{a)) = h{choice{f {a))) = h{a), and 
therefore h = g ■ f. □ 



VA,B,C;Ui. Vf:A — > B. Vh:A ^ C. 

Dec(C) => (Vb:B. Dec(3a:A. b = f a)) => 

((3g:B — >C. h = gof)«^= ker[A,B]f C ker[A,C]h A B — >■ C) 

Fig. 15. Theorem: kernel_inclusion_implies_postf actor 

To give a constructive proof that the inclusion of kernels implies the existence 
of postfactors, we made two additional assumptions compared to the statement 
of this lemma in [6]: i.) that we can decide whether the codomain of h is empty, 
and ii.) that we can decide whether an element in the codomain of / is in 
the image of /. The Nuprl theorem kernel_inclusion_implies_postf actor is 
shown in Figure 15. The formal proof is about 43 steps long. 

^ To prove that such a function choice exists, we use the Axiom of Choice which is 
provable in constructive type theory [12] and is a theorem in the Nuprl standard 
library. 
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Figure 16 shows a “lifted” version of the lemma for arrows in the category of 
types. Despite the use of the original lemma in the proof of the lifted version, 
the proof is about 71 steps long. 



VA,B ,C: large_category{i}_Obj . Vf :Mor [large_category-[i}] (A,B) . 

Vh:Mor [large_category{i}] (A,C) . 

Dec(C) (Vb:B. Dec(3a:A. b = f.2.2 a)) ^ 

( Og:Mor [large_category-[i}-] (B,C) . h = g large_category{i}_op f) 

ker [A,B] f . 2 . 2 C ker [A,C]h.2.2 A Mor [large_category-[il] (B,C) ) 

Fig. 16. Theorem: kernel_inclusion_implies_postf actor_cat 

The second lemma required for the proof of Thm. 7 is stated below. 

Lemma 2. If F : SEF — > SET is a functor with an initial algebra {fiF,in), and 
A is a set such that we can decide whether A is empty, then 

A^tD fA^ A^tD. 

Proof. If A 0, then trivially F A ^ A ^ tb. 

li A = b, then the embedding g : A ^ fiF is a function from A to pF. Thus 
Fg : FA — > F{pF) by the properties of functors. Hence h ■ in ■ Fg : FA A. 
Therefore FA ^ H yf 0 in either case. □ 



Fg 

F(pF) ''fa 



f 



pF 






9 



h 



7 

A 



Fig. 17 . pF ^ A FA^ AA^- 



Figure 17 illustrates the situation: Given a function h : pF A, we can find 
a function f : F A ^ A. The functions g : A ^ pF and Fg : FA ^ F{pF) 
are needed only in the case H = 0. If H y^ 0, they may not exist - but we can 
construct a function f : FA ^ A directly then. Note that the lemma is not true 
for arbitrary categories. The proof of the lemma given above is different from the 
proof that was given in [6]^, but the theorem h.om_fun_implies_algebra_fun 
(which is shown in Figure 18) is proved along the same lines. The formal proof 
is about 49 steps long. 

® The differences between our proofs can be attributed to the empty type issue men- 
tioned earlier, but also because we avoided the form of contrapositive used there, 
{-^p -ig) {q ^ p), which is not constructively valid. 
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VF : Functor-Ci ’ } (large_category{iJ , large_category{iJ) . 

VI : {I : Algebra(F) I algebra_category(F)-initial(I)J . 

VA : large_categoryCiJ_Obj . Dec (A) 

Mor [large_category-[iJ] (I_obj ,A) =>Mor [large_category{iJ] (F_0 A, A) 



Fig. 18. Theorem: hom_fun_implies_algebra_fun 



We are now ready to prove Theorem 7. 

Proof. 

ker{Fh) C ker(ft, • in) 

{ Lemma 2, h : ^ A } 

ker{Fh) C ker(h • in) A FA — > A 0 
{ Lemma 1 } 

3g : FA ^ A. h ■ in = g ■ Fh 
{ universal property } 

3g : FA A. h = fold g. 

□ 

Clearly we can decide whether an element in FA is in the image of Fh 
when Fh is surjective (onto). We will show that Fh is surjective if h is. There- 
fore every surjective function that satisfies the condition of kernel inclusion is 
a catamorphism if we can decide whether its codomain A is empty^. We could 
relatively easily prove this as a corollary to Theorem 7. Closer inspection of the 
proof of Theorem 7 however shows that when h is surjective, we do not need the 
additional assumption that we can decide whether A is empty. 

Theorem 8. Suppose F : SET — > SET is a functor with an initial algebra 
{gF, in), and h : pF A is surjective. Then 

{3g : FA — > A. h = foldg) <J= ker(Fh) C ker(/i • in). 

We first prove that a function is surjective if and only if it is right-invertible 
in SET. 

Lemma 3. Suppose f : A ^ B. Then 

f is surjective / is right-invertible in SET . 

Proof. For the (^) direction, suppose / is surjective. Then there exists a function 
g : B ^ A such that f{g{b)) = b for all b G B (by the Axiom of Choice). Hence 
f ■ g = id{B), so / is right-invertible. 

For the (<J=) direction, suppose / is right-invertible in SET. Then f-g = id{B) 
for some function g : B ^ A. Now let b G B. Then f{g{b)) = (/ • g){b) = 
{id{B)){b) = b. Therefore / is surjective. □ 

Note that every injective (one-to-one) function is a catamorphism by Theorem 3. 
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Figure 19 shows a formalization of the lemma in Nuprl. The formal proof 
is about 33 steps long and makes use of the ax_choice lemma from the Nuprl 
standard library. 

VA,B:Ui. Vf:A ^ B. 

Surj(A;B;f) < — > right-invertible [large_category{i}] (<A, B, f>) 

Fig. 19. Theorem: surjective_iff _right_invertible 

We also state and prove a lifted version of the lemma for arrows in the cate- 
gory of types. This lifted version is shown in Figure 20. Lifting the lemma requires 
about 11 proof steps using the lemma surjective_iff_right_invertible. 

Vf : large_category{i}_Arr 

Surj (large_category-[i}_dom f ; large_category{i}_cod f;f.2.2) 

— > right-invertible [large_category-[i}-] (f) 

Fig. 20. Theorem surjective_iff_right_invertible_cat 

We now prove a lemma similar to Lemma 1, but for surjective functions. 

Lemma 4. Suppose f : A ^ B is surjective, and suppose h : A ^ C. Then 
{3g : B ^ C. h = g ■ f) <J= ker / C ker h. 

Proof. Assume ker / C ker h. 

Let choice : i? — > A be a function with f{choice{b)) = b for all b G B (such 
a function choice exists by the Axiom of Choice since / is surjective). Define 
g ■. B ^ C hy g{b) = h{choice(b)) for every b G B. 

Now h = g ■ f hy construction of g: Let a G A. Since f{choice{f{a))) = f{a) 
by definition of choice, {choice{f{a)), a) G ker / C kerh. Therefore g{f{a)) = 
h{choice{f{a))) = h{a). □ 

Figure 21 shows a formalization of this lemma in Nuprl. The formal proof re- 
quires about 14 steps. It is similar to the proof of kernel_inclusioii_implies_ 
postfactor, but slightly simpler - just like the informal proof. 

VA,B,C:Ui. Vf:A B. Vh:A ^ C. Surj(A;B;f) ^ 

(Og:B — > C. h = gof) ker[A,B] f C ker[A,C] h) 

Fig. 21. Theorem: kernel_inclusion_implies_postf actor_surjective 

As for the kernel_inclusion_implies_postf actor lemma above, we prove 
a lifted version of this lemma for arrows in the category of types. The lifted 
version is shown in Figure 22. Its proof is similar to the proof of the lifted 
lemma for functions with a decidable image (see Figure 16) and requires about 
47 steps. 

VA,B ,C: large_category{i}_Qbj . Vf :Mor [large_category-[i}] (A,B) . 

Vh:Mor [large_category{i}] (A,C) . Surj (A;B;f .2.2) ^ 

( (3g:Mor [large_category-[i}] (B ,C) . h = g large_category{i}_op f) 
ker[A,B] f.2.2 C ker[A,C] h.2.2) 

Fig. 22. Theorem: kernel_inclusion_implies_postf actor_surjective_cat 

Using the two Lemmata 3 and 4, we can now prove Theorem 8. 
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Proof. We first show that Fh : F{^F) — > FA is surjective. Since h is surjective, 
h is right-invertible by Lemma 3. Let g ■. A ^ g,F be a function with h-g = id(A) . 
Then 



Fh- Fg 

= { functors } 

F{h ■ g) 

= { assumption } 

F{zd{A)) 

= { functors } 

id{FA). 

Hence Fh is right-invertible, and therefore surjective (again by Lemma 3). Now 

ker(T'/i) C ker(/i • in) 

{ Lemma 4 } 

3g : FA — > H. h ■ in = g ■ Fh 

{ universal property } 

3g : FA —> A. h = fold g 



completing the proof. □ 

See Figure 23 for a statement of this theorem in Nuprl. We use the lemma 
kernel_inclusion_implies_postf actor_sur jective_cat to prove the exis- 
tence of g, and surjective_iff_right_invertible_cat to prove that Fh is 
surjective. Altogether the formal proof requires about 145 steps. 

VF : Functor-fi ’ } (large_category{i} , large_category{i}) . 

VI : {I : Algebra(F) I algebra_category(F)-initial(I)J . 

VA : large_category-[i}-_Obj . Vh:Mor [large_categoryCiJ] (I_obj ,A) . 

Surj (I_obj ; A;h.2.2) ^ 

( (3g: Algebra(F) . h=fold[large_category{i},F,I] (g) ) 

ker [F_0 I_obj , large_category-[i}-_cod (F_M h)] (F_M h).2.2 
C ker[F_0 I_obj ,large_category{i}_cod (h F_dom_op I_arr)] 

(h F_dom_op I_arr).2.2) 

Fig. 23. Theorem: kernel_inclusion_implies_f old_surjective 

We now have two simple conditions for when a constructive function h that 
satisfies the condition of kernel inclusion is a catamorphism: h is a catamorphism 
if the image of Fft, is decidable and we can decide whether the codomain of h is 
empty, and h is a, catamorphism if h is surjective. 

6.2 A Small Example 

Embedded in the constructive proof of Thm. 7 is an algorithm to compute a 
function g such that h = fold g. As an example, we want to apply this algorithm 
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to the function all, defined by all p L = and (map p L) . Here L is a list over 
some type T, and p : T — > B. This function computes whether all elements in 
L satisfy the predicate p. To do so however, the implementation first iterates 
over L to compute an intermediate list of boolean values, and then it iterates 
over the list of booleans to compute their conjunction. Writing all directly as 
a catamorphism would eliminate the need for an intermediate list. 

Before we can prove that all can be written as a catamorphism, we have to 
show that List{T) is the object of an initial algebra. Consider the functor Ct ■ 
SET ^ SET, defined by Ct{A) =1 + {TxA) and £t(/) = id{l) + {id{T) x /). 
Formally verifying that this is in fact a functor takes about 54 proof steps in 
Nuprl. This functor has an initial algebra {pCx, in) = {List{T),nil + cons). To 
verify initiality, we have to show that for every other algebra {A, f) there exists 
a unique homomorphism h from {List(T),nil + cons) to (A,f). Since /i is a 
homomorphism, h([]) = f{inl •) and h{u :: v) = f{inr (u,h{v))) for all u € T, 
V C List(T). Both that h is a homomorphism and that h is unique can then be 
proved by structural induction on lists. The formal proof is quite technical, and 
complicated by our inevitable formalization of algebras, homomorphisms and 
arrows in the category of types as tuples. With approximately 211 proof steps, it 
is the longest proof in this paper. About 140 of those steps are required only to 
show uniqueness of h. However, initiality only needs to be proven once for each 
data-type. Having proven initiality of List{T), we can treat any list-consuming 
function, not just all. 

Using the kernel_inclusion_implies_f old theorem, we can now prove 
that the composition of map and and is a catamorphism. We need just one 
more assumption: that we can decide for all 6 G B whether there exists a 
list L G ListiT) with b = and (map (p; L)). Since and(map(p; [])) = true, it is 
sufficient if we can decide whether p(t) = false for some t G T. (If there is 
such a t, false = and(map(p]t :: [])). Otherwise and (map (p] L)) = true for all 
L G List(T). This argument is reflected in the structure of the resulting pro- 
gram.) Figure 24 shows the Nuprl theorem list_and_ 2 _map_is_f old. 

* THM list_and_2_map_is_f old 
VT:U. Vp:T ^ B. 

Dec(3t:T. p t = false) 

=> (3g: Algebra(ListF{i}(T) ) 

<T List, B, AL . Ab (mapCp; L) )> = 

fold[large_categoryCi}-,ListF{i}(T) ,InitialAlgebra(ListF(T))] (g) ) 

Fig. 24. Theorem list_and_2_map_is_f old 

We can unfold its extract (and the extracts of other lemmata that were used 
in its proof) to obtain the actual function g with and(map(p\ •)) = fold 5 . This 
function (with a few simplifications made by hand) is shown in Figure 25. The 
first and second component of the triple are the function’s domain and codomain, 
respectively. The if-then-else statement is used to determine whether x G 
1 -I- (T X B) is in the image of £T(nnd(map(p; ■))). Three cases need to be 
distinguished: x = ini ■, x = inr (yl,true), and x = inr (yl, false). The latter 
can only occur iip(t) = false for some t G T; whether such a t exists is determined 
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by the value of ip. If x is in the image of CT{and{map{p; •))), the then part is 
used to apply and{map{p\ •)) • {nil + cons) to an element z G 1 + (T x List{T)) 
with {CT{and{map{p; -))))(z) = x. Otherwise, an arbitrary boolean (in this case 
true) is returned in the else part. 

< (ListF{i}(T)_0 B) 

, B 

, Ax. if case x 

of inl(_) => true 
I inr(<yl,y2>) => case y2 
of inl(_) => true 
I inr(_) => case p 
of inl(_) => true 
I inr(_) => false 

then (<T List, B, AL . Ab (niap(p;L) ) > ListF{iJ(T)_dom_op 
InitialAlgebraCListF (T) ) _arr) .2.2 
(case X 

of inl(_) => <inl •, Ax> 

I inr(<yl,y2>) => case y2 

of inl(_) => <inr <yl, []> , Ax> 

I inr(_) => case p 

of inl(<t,_>) => <inr <yl, t::[]>, Ax> 

I inr(_) => arbitrary) 

else true 
fi > 



Fig. 25. A function g with and{map{p\ •)) = fold g 

The function shown in Figure 25 is unlikely to be more efficient than the 
initial composition of and and map, due to the increased overhead associated 
with each list element. However, we could further simplify the function by using 
and{map{p; [])) = true and and{map{p;t :: [])) = false and combining the two 
outermost case constructs (which have identical structure). 



6.3 Constructively Characterizing unfold 

Now we consider reformulating the (4=) direction of Theorem 6. To prove it, we 
identify additional assumptions under which the inclusion of images construc- 
tively implies the existence of prefactors. Dualizing our results for kernels and 
postfactors, one could suspect that (among other things) we need to be able to 
decide whether the domain of h is empty. However, it turns out that the classical 
proof of the (4=) direction of Theorem 6 given in [6] can be simplified signifi- 
cantly. In particular, the dual of Lemma 2, although easily provable in Nuprl 
(see Fig. 26), turns out not to be needed. 

VF : Functorfi ’ } (large_category{iJ , large_category{i}) . 

VT: {T: Coalgebra (F) I coalgebra_category(F)-terminal(T)}- . 

VA : large_categoryCi}-_Obj . Dec (A) => 

Mor [large_categoryCi}] (A,T_obj ) Mor [large_categoryCi}] (A,F_Q A) 



Fig. 26. Theorem: cohom_fun_implies_coalgebra_fun 
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Therefore it is sufficient to replace the precondition \mg{out-h) C img(F/i) by 
the (classically equivalent) condition Vc G \mg{out ■ h). 3b G FA. c = {Fh){b) 
to give a constructive proof. We first prove that the latter condition implies the 
existence of prefactors. 

Lemma 5. Suppose that f : B ^ C and h : A ^ C , where A, B, C are sets. 
Then {3g : A ^ B. h = f ■ g) <;= (Vc G imgh. 3b G B. c= f{b)). 

Proof. Assume Vc G \mgh. 3b G B. c = f{b). Let choice : imgft, ^ B he a, 
function with f{choice{c)) = c for all c G img/i. Now define g = choice ■ h. Then 
(/ • g){a) = f {choice {h{a))) = h{a) for every a G A, hence h = f ■ g. □ 

Note the difference between Lemma 5 and [6, Lemma 5.3]: our proof does not 
need A — s- i? 0 as an additional assumption. Figure 27 shows the corresponding 

Nuprl theorem, which is proved in 19 steps. As usual, we prove a lifted version 
for arrows in the category of types. This lifted version is shown in Fig. 28; using 
the image_inv_fun_implies_pref actor lemma, it is proved in 45 steps. 

VA,B,C:Ui. Vf:B — >■ C. Vh:A — >■ C. (3g:A ^ B. h = f o g) 

■<= ( Vc : img [A , C] h. 3b :B. c = f b) 

Fig. 27. Theorem: image_inv_fun_implies_pref actor 



VA,B,C: large_category{i}_Dbj . Vf :Mor [large_category-[i]-] (B,C) . 

Vh:Mor [large_category{i}] (A,C) . 

(3g:Mor [large_category{i}] (A,B) . h = f large_category-[i]-_op g) 
(Vc:img[A,C] h.2.2 3b:B. c = f.2.2 b) 

Fig. 28. Theorem: image_inv_fun_implies_pref actor_cat 

Our main result for anamorphisms is now immediate. 

Theorem 9. Suppose F : SET — > SET is a functor with a terminal coalgebra 
{r'F, out), A is a set, and h : A vF . Then 

{3g : A ^ FA. h = unfold g) (Vc G img{out ■ h).3b G FA. c = {Fh){b)). 

Proof. 

Vc G \mg{out ■ h). 36 G FA. c = (Fh){b) 

{ Lemma 5 } 

3g \ A FA. out ■ h = Fh ■ g 
{ universal property } 

3p : A — > FA. h = unfold g. 



□ 

Theorem image_inv_fun_implies_unf old, shown in Fig. 29, is the corre- 
sponding Nuprl theorem. Again mostly due to well-formedness goals, the formal 
proof requires about 91 steps. 
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VF : Functor-Ci ’ }(large_category{i} , large_category{i}) . 

VT: {T: Coalgebra (F) I coalgebra_category(F)-terminal(T)}- . 

VA : large_category-[i}-_Obj . Vh:Mor [large_categoryCiJ] (A,T_obj) . 
Og: Coalgebra (F) . h=unf old [large_category-[i}-,F,T] (g) ) 

(Vc : img [A,F_0 T_obj] (T_arr F_dom_op h).2.2 
3b:F_0 A. c = (F_M h).2.2 b) 



Fig. 29. Theorem: image_inv_fun_implies_unf old 



7 Conclusions 

We have presented a constructive characterization of fold and unfold which we 
believe is of interest, independent of the formalizations presented here. However, 
we have completely formalized these results in Nuprl. The extract of Thm. 7 was 
applied to a small example involving the reformulation of the program all p L 
= and (map p L) as a fold. The hardest part of that proof was to show that the 
inductive type List{T) is in fact the object of an initial algebra. However, proofs 
of initiality or finality only need be done once for each data- type. We have also 
proven finality for the coinductive type StreamiT) and exercised the extract of 
Thm. 9 on a simple stream-generating function. 

The presented program transformations could be used in an optimizing com- 
piler to transform any function that meets certain (rather simple) semantic cri- 
teria into a fold or unfold. No knowledge of the function’s implementation is 
required. Of course this generality comes at a price: the semantic properties that 
must be verified are, like all non-trivial semantic properties, not decidable in 
general. The compiler could analyze the function in question to try and prove 
these properties automatically, it could rely on human guidance, or it could use 
a combination of both approaches. 

In the longer term, we hope to incorporate a wide variety of program trans- 
formations into the framework outlined here. 
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Abstract. Higher-order patterns, together with higher-order matching, 
enable concise specification of program transformation, and have been 
implemented in several program transformation systems. However, 
higher-order matching in general is nondeterministic, and the match- 
ing algorithm is so expensive that even second-order matching is NP- 
complete. It is orthodox to impose constraint on the form of patterns to 
obtain the desirable matches satisfying certain properties such as decid- 
ability and hniteness. In the context of unification, Miller’s higher-order 
patterns have a single most general unifier. We relax the restrictions in 
his patterns without changing determinism within the context of match- 
ing instead of unification. As a consequence, the new class of patterns 
covers a wide class of useful patterns for program transformation. The 
time-complexity of the matching algorithm is linear for the size of a term 
for a fixed pattern. 

Keywords: Higher-order pattern matching; Functional programming; 
Program derivation; Program transformation; Fusion transformation 



1 Introduction 

Patterns, together with pattern matching algorithms, play an important role in 
the specification of transformation rules as well as the implementation of trans- 
formation systems. Usually, the more flexible the patterns are, the more difficult 
it is to design efficient matching algorithms. Although first-order patterns are 
simple and first-order matching algorithms are cheap and deterministic, these 
patterns lack descriptive power. In contrast, although the second- (or higher-) 
order patterns [1-3] are flexible enabling powerful transformation to be concisely 
specified, second-order matching algorithms are expensive and nondeterministic. 

Consider, for example, fusion transformation [4, 5] , which is used to optimize 
programs by eliminating the unnecessary intermediate data structures that are 
passed between functions. The basic fusion transformation rule (in Haskell-like 
notation [6]) is: 

yx,y.x(^ f y = f{x®y) 
f . foldr (0) e = foldr (0) (/ e) 

M. Bmynooghe (Ed.): LOPSTR 2004, LNCS 3018, pp. 128-142, 2004. 

© Springer- Verlag Berlin Heidelberg 2004 
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which states that a composition of function / with a foldr can be fused into a 
single foldr, provided one can find function 0 satisfying the side condition, i.e., 

x(^fy=f{x®y) . 

Note that the key step in fusion transformation is to find function 0 meeting 
the side condition. This is actually a higher-order matching problem: matching 
higher-order pattern \xy.x® f y with term^ \x y. f {x® y) to obtain a substi- 
tution (definition) for pattern variable (8>. To be more concrete, let us look at the 
fusion of the following program to compute the sum of squares of each element 
of a list^. 

sumsq = sum . foldr {\xy. x * x : y) [] 
where sum [] =0 

sum {x : xs) = x + sum x 

Expanding the right-hand side of the fusion condition, we get 

\xy.f {x®y) 

= { instanciating © } 

Ax y. sum {x * x : y) 

= { definition of sum } 

Xxy.x * X + sum y 

We then obtain 0 by matching the resulting term, Xxy.x * x + sum y, with 
pattern Xxy.x ® sum y. This pattern is beyond Miller’s higher-order pattern, 
and match 

{(g) 1 -^ Xyi y 2 -yi *J/i + 2 / 2 } 

cannot be obtained by first-order matching. Our approach, on the other hand, 
can deal with such patterns and guarantee a unique match. 

Despite the attractive power of higher-order patterns and higher-order match- 
ing, there have been several significant objections to the use of higher-order 
matching for implementing program transformation, particularly in functional 
languages. 

— First, higher-order matching is known to be so expensive that even second- 
order is NP-complete [7]. Therefore, really efficient implementation is out of 
the question. 

— Second, higher-order matching algorithms are generally nondeterministic, 
resulting in more than one solution. Unlike logic languages such as Prolog, 
which deal with this sort of nondeterminism by means of backtracking, it 
cannot be directly handled by functional languages. 

— Last, although solutions to the matching problem can clearly be specified, 
nondeterminism makes the semantics complex and it is often difficult to 
explain why a particular match was not produced. 

^ Strictly speaking, the term should be normalized before being matched with a pat- 
tern. 

Here binary operators (.), (*), (:), and (+) are constants. 
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Fortunately, experience in implementing program transformation systems 
tells that it is not really necessary to have fully flexible higher-order patterns 
and higher-order matching in practice. We may, therefore, think of imposing rea- 
sonable restrictions on the form of patterns to generate desirable higher-order 
matching that is both deterministic and efficient. It is known that by restricting 
the form of patterns, one can make possibly undecidable fifth-order matching 
decidable [8], and infinite third-order matching finite [2]. 

Within the context of unification. Miller defined a class of higher-order pat- 
terns [9]. In his higher-order patterns, each occurrence of free variables should 
be applied to a sequence of distinct bound variables. For example, the pattern 

Xxy.p y X 

is valid, since free variable p appears at the head of application pyx and the 
arguments of p, namely x and y, are distinct bound variables. However, the 
patterns oi Xx.p x x where p has the same bound variable x, Xx.p {x-\-x) where 
the argument {x-\-x) of p is not a variable, and p q where the argument g of p is not 
a bound variable, are all invalid. It has been proved that general higher-order 
unification (matching) with respect to Miller’s patterns is deterministic, and 
this has been implemented [10]. Miller’s patterns are, however, too restrictive 
to describe program transformation rules. For instance, the arguments of free 
variables in a pattern may be complicated terms instead of variables, as can be 
seen in the fusion law where the arguments of free variable ® in the pattern are 
X and / y. 

In this paper, we relax the restriction of Miller’s higher-order patterns by 
allowing the arguments to be terms, and propose new class A of patterns, with 
the following features. 

— Class A covers a wider class of patterns that are often used in specifying 
program transformation and program calculation. It enables the fusion law 
to be concisely described. This is very important, as fusion law plays an 
essential role in program transformation and calculation [11, 12] and many 
other transformations can be formalized using this law. 

— The higher-order matching algorithm for any patterns in class A is as simple 
and efficient as a first-order matching algorithm. 

The organization of the paper is as follows. Section 2 gives a formal definition 
for class A. In Section 3, we prove the determinism of our matching algorithm 
with respect to patterns in class A. In Section 4, we present an efficient algo- 
rithm, and prove its soundness and efficiency. We briefly explain related work in 
Section 6 and conclude the paper in Section 7. 

2 Deterministic Higher-Order Patterns 

We consider simply typed lambda terms recursively defined by constants, vari- 
ables, applications, and A-abstractions as follows. 



T = c\v\TT \ Xx.T 
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Let FV be a function mapping from a term to a set of free variables in the term. 
For example, FV (Ax. p x) returns p. We call term E closed if FV (E) = { } . For 
readability, we sometimes use the infix notation, so x + y denotes term (-I-) x y. 
A /3-redex is an expression of the form (Ax. i?) E; a /3-reduction replaces a 
/3-redex with body B where every occurrence of bound variables x is replaced 
by argument E. An ?7-redex is an expression of form Xx. E x where E does not 
contain x, which is 77-reduced into E. We call a term f 3 -normal if the term does 
not contain any /3-redex, and similarly we call term rj-normal if the term does 
not contain any ?7-redex. We call /3?7-normal normal. We sometimes write Xx.p E 
for Axi • • • Xxi .p El' ■ ■ Em ■ 

We say that a term E\ is a suhterm of E2, denoted by E\ < E2, if 
El € subTerm{E2) (here a-renaming is implicitly assumed), where subTerm is 
defined below: 

subTerm{c) = {c} 

subTerm{v) = {v} 

subTerm{Ei E2) = {Ei E2} U subTerm{Ei) U subTerm{E2) 
subTerm{Xx. E) = {Ax. E} U subTerm{E) 

We call terms Ei{l < i < m) distinct iff each Ei is not a subterm of the others. 
Let V Ti ■ ■ ■ T„ a subterm and v a variable. We call Ti, . . . , T„ arguments of x, 
and call v the head of the subterm. 

We call a term flexible iff the head of the term is a free variable, otherwise 
we call it rigid. 

A eontext C[] is a term with some holes in it. Note that a free variable in T 
may become bound in C[T]. 

A substitution (or match) is mapping from variables to closed terms and 
denoted 

4 > = {p Xx. X b} . 

We denote the domain of substitution (j) as dom{(j)). The composition of sub- 
stitutions (j) and Tp is defined if the substitutions are compatible, i.e., the same 
variables in domains have the same ranges: 

Vx G dom{ 4 >) n dom{ip) . p v =a/37j ip x , 

where the equality operator (=af}ri) is modulo a/Jry-conversion. Otherwise, it will 
return the special match fail. Note that fail is the zero of match composition, 
i.e., 

fail om = mo fail = fail . 

For example, the composition of substitutions {p c} o {p 1-^ Xx. x} is fail . 

Types are constructed in the usual way in simply typed lambda calculus. Let 
To be a set of base types. Type set T is defined as follows. 

a G Tq ^ a G T 
a,fl GT ^ (3 GT 
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The order of type r ord{r) is defined as follows. 

ord{a) =1, if a G Tg 
ord{a ^ (3) = max{ord{a) + 1, ord{j3)} 

The order of any base type is 1. The order of function types is a maximum of 
one plus the order of the argument type and the order of the result type. The 
order of a term is defined as the order of its type. 

Given term P and closed term T where P and T are normal, a matching pair 
is a pair of terms written as P ^ T. We call P the pattern for the matching pair. 
The order of a pattern is the maximum order of free variables in the pattern. 

The general matching problem is defined as follows. Given matching pair 
P ^ T, find all substitutions </> such that 4> P =a/ 3 rj T. We call this substitution 
match, and write (j) \- P T to indicate that is a match of matching pair 
P ^ T. If matching produces at most one (j) such that (j> \- P ^ T, i.e., 

V(/)iV02. ^1 hP^T A (j)2 P ^ T ^ (pi =a/37j (p2 , 

we say it is deterministic, or simply say that (j> \- P ^ T is deterministic. We 
call a class of higher-order patterns deterministic higher-order patterns (T>HV) 
iff matching a pattern in this class with a closed term will give at most one 
match. The order of the matching problem is the order of the pattern. We call 
more than a first-order matching problem a higher-order matching problem. 

In this paper, we use the following notational convention. We use a, b, c, 
and d, strings starting from small letters, and binary operators (-I-) and (*) to 
represent constants, and use other small letters such as e, p, v, x, and operators 0 
and 0 to represent variables. We will use p, q, and r to denote the free variables 
and w, X, y, and z to denote bound variables to distinguish these in a pattern. 
We use the Greek identifiers </>, ip, and cr to represent matches, and capital letters 
such as B, E, P, T to represent patterns and terms. 

We are now ready to define class A of patterns. We will see later that patterns 
in this class are VhCP, i.e., matching a pattern in this class with a closed term will 
give at most one match. The class of patterns is a simple extension of Miller’s 
higher-order patterns, which has at most single most-general unification; the 
arguments of every free variable in the pattern must be distinct and be bound 
variables. 

Definition 1. Term P is class A, iff arguments E\, ... , Em of any free variable 
occurring in a normalized term of P satisfy the following conditions. 

(i) Vz.PM(P,)^{} , 

(ii) ^i,j.iff j ^ E^^ Ej , 

(iii) Vz. {v G EV{Ei) v ^ FV{P)) , and 

(iv) For all i, Ei is not a X- abstraction. □ 

The conditions for arguments are a relaxation of Miller’s idea from “distinct 
and bound variables” to “non-mutually embedded terms containing bound vari- 
ables”: (i) Ei should not be a closed term. For example, term p 1 is not of class 
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A because argument 1 is closed, (ii) For all i,j{i ^ j), Ei is not a subterm of 
Ej. Therefore, Xx. p x (x -I- 1) is not of class A since argument a: is a subterm of 
another argument x+1- (iii) Free variables in Ei should be bounded in pattern 
P. As a result, p q\s not of class A. (iv) For example, p {Xx. x) is not of class 
A because argument (Ax. x) is a A-abstraction. 

Class A covers a wide class of useful patterns for describing transformation 
rules. Pattern Xxy.x ® f y va the fusion law discussed in the introduction is of 
class A. Another example is, the following pattern of a class A 

Xw x.if p X then q x else r {car x) {w {cdr x)) , 

which is used to extract a specific program structure. This pattern is beyond 
Miller’s higher-order patterns since the arguments of free variable r are not 
variables. Matching this pattern with the program 

Xreversex. if null x then x else 

append {reverse {cdr x)) {cons {car x) nit) 

gives the unique match 

{p null, q > Ax. x,r Xz w. append w {cons z nit)} , 

and matching the pattern with the program 

Xmapsquarex. if null x then x else 

cons {square {car x)) {mapsquare {cdr x)) 

gives another unique match 

{p null, q 1 -^ Ax. x,r Xz w. cons {square z) re} . 

We will discuss the matching algorithm later. 

3 Deterministic Higher-Order Matching 

Thus far, we have given the definition of class A of patterns, where matching 
a term with one of these patterns is guaranteed to produce a unique match if 
one exists. We prove this in this section, and in Section 4 describe an efficient 
algorithm to obtain the match. 

To begin with, let us introduce the important concept of discharging sub- 
terms. Discharging E\,. . . , Em by yi, . . . , ym in T means replacing all occur- 
rences of Ai, . . . , Em with fresh variables yi,. . . , ym respectively in T. One pos- 
sible implementation is given in Fig. 1. Intuitively, the function 

discharge [{yi,Ei), ..., {ym, Em)] T 

replaces all occurrences of Ei, ... , Em with fresh variables yi, . . . , ym respectively 
in T. That is 

B = discharge [{yi,Ei), . . . , {ym, Em)] T A Vz. Ei is not a A-abstraction 
{Xy. B) E =af}ii T A Vi. Ei ^ B . 
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discharge s c = c 
discharge s v = replace s v 
discharge s (Ax. Ti) = 
let T' = replace s (Ax. T\) 

in if T' — (Ax. Ti) then Ax. {discharge s T\) else T' 
discharge s (Ti T2) = 
let T' = replace s (Ti T2) 
in if T' = (Ti T2) 

then {{discharge s Ti) {discharge s T2)) 
else T' 

replace [] T = T 
replace {{y,E) : s) T = 

if E = T then y else replace s T 

Fig. 1 . Discharging Algorithm 



Redundant traversing of equality check in function discharge in Fig. 1 can be 
removed by tupling transformation. 

Lemma 2. If P = \x. p E is of class A where p is a free variable, then there 
is at most single match <f> such that <f\- P ^ T . 

Proof. We assume that P, T, and E are all in normal form. There is no match 
if T is not transformed into Ax. T' by a? 7 -conversion. The match of matching 
pair p E ^ T' should have the form {p \y.B}. There is no loss of gen- 
erality if we assume B is in normal form. Since free variables in each Ei are 
bounded in P by Definition l.(iii), due to the definition of matching, equation 
{\y. B) E =a/ 3 rj T' should be satisfied. Therefore, term B is the result of replac- 
ing E with y in T' , since B is in normal form and Ei is not a A-abstraction. 
Through Definition l.(i), subterms Ei {1 < i < m) contain free variables and 
if we leave any occurrences of Ei in B, then Xy. B will contain free variables. 
This generates an illegal substitution containing free variables. Instead, term B 
should be obtained through full discharging; replacing all occurrences of E with 
y in T', i.e, {Xy. B) E =a/ 3 ri T' A Vi. Ei ^ B. If some free variables still occur 
in B after discharging, this results in illegal substitution. Otherwise, since one 
argument is not a subterm of another argument by Definition l.(ii), the order of 
replacing does not affect the result of the match. Thus, the match is obtained 
deterministically. □ 

Note that similar to the proof, we can use any discharging function satisfying 
the condition 

{Xy. B) E =af}-q T' A 'di.EiflB , 

for discharging arguments of free variables in class A. In the following, we use the 
function discharge for discharging arguments from a term. Our main theorem is 
given below. 
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Theorem 3 (Deterministic Higher-order Matching). If P is of class A, 
there is at most single match (f> such that <f>\- P ^ T . 

Proof. We use mathematical induction on the structure of the pattern. 

Case {P = Xx. c E). There is no match if the corresponding term cannot 
be transformed into Xx. c F hy ary-conversion where the lengths of E and 
F are equal. Otherwise, matching can be decomposed into m matchings 
(fi h Xx. Ei Xx. Fi ior i = 1 . . .m. By induction hypothesis, each match 
4>i\- Xx. Ei ^ Xx. Fi is unique or there is no match in which case (fi = fail. 
Therefore (j)' \- P ^ T is a, unique match or there is no match if <j)' is a fail 
where <f>' = (fi o ■ ■ ■ o <f.^. 

Case (P = Xx. v E Av^ FV{P)). Similar to the first case. 

Case (P = Ax. v E Av G FV{P)). Through Lemma 2, the match generated by 
the pattern is unique or there is no match. □ 

For example, consider P = Ax. p (c x) {d x) and term T = Ax. a (c x) {b {d x)) 
where a, b, c and d are constants, p and x are variables, and p occurs freely in 
P. To match P against T, we replace c x and d x with fresh variables y\ and 7/2 
in T resulting in the unique match {p Xyi 7 / 2 - a 7/1 {b 7 / 2 )}. 

4 Efficient Deterministic Higher-Order 
Matching Algorithm 

Given matching pair P ^ T where P is of class A, algorithm At | P — > P] , defined 
in Fig. 2 computes a unique match if one exists. Otherwise, it returns the special 
match fail. For example, M{c Xx. d} returns fail. In Fig. 2, the first case acts 
as ? 7 -expansion, so, M[ Xx.p (c x) ^ c] returns M\ Xx. p {c x) ^ Xx. c X ] . The 
second and third cases correspond to ones in our proof of Theorem 3. If the 
heads of the pattern and the term are equal and the lengths of their arguments 
are the same, the matching pair is decomposed into smaller ones. The fourth 
case which calls the function discharge for exhaustive discharging corresponds 
to Lemma 2. An example of this is 

M\ Xar.a® sum r ^ Xar. a * a + sum r ] , 

which computes the following match 

{'^ Xxy. {discharge [{yi, a), {y 2 , sum r)] {a*a + sumr))} . 

Formally, we can prove the soundness of algorithm Af , i.e.. At will return a 
unique match if there is one. Here, 3!x. P means that there is exactly one x such 
that P. 

Theorem 4 (Soundness). If P is of class A, then 

yT3l(j).(j)h P^TAA<p = M[P^Tj A (py^fail . 
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M\\x\ ■ ■ ■ xi. Pi ^ \x\ ■ ■ ■ Xo- Ti\ = 

M\\xi ■ ■ ■ xi. Pi ^ Xxi ■ ■ - xi. Ti Xo+i ■ ■ - xi] 
if o < I A Pi and Ti are not A-abstraction 
M\ \x. c El ■■■ Em ^ Xx. d Ti ■ ■ ■ Tm] = 

A4[Xx. El Xx. Ti ] o • • • o A4[Xx. Em —> Xx. Tm ] 
if c = d 

M{ Xx. Xi El ■■ ■ Em Xx. Xj Ti ■ ■ ■ Tm] = 

M[Xx. El Xx. Ti ] o • • • o M\Xx. Em Xx. Tm ] 
if i = j 

M\ Xx. p El ■ ■ ■ Em Xx. Ti ] = 

{p Aj/i • • • ym. B} 
if Xyi ■ ■ ■ ym.B is closed 

where 

yi, ... ,ym are fresh variables 
B = discharge [{yi, Ei),. . . , (ym, E m )1 Ti 

-^ 1-1 = fail 

Fig. 2. Matching Algorithm 

Proof. We prove this through this induction on the structure of the pattern. 
We calculate as follows for the first case of matching algorithm Ai, 

3\(j). <j) = M .\ Axi ■ ■ ■ xi. P\ Xxi ■ ■ ■ Xq. Ti ] 

{ ? 7 -conversion } 

3\<f>.<l) = Ai\Xxi ■ ■ ■ xi. P\ Xxi • • • xi.Ti Xo+i ■ • • xi] 

{ induction hypothesis } 



([) h Xxi • 


■■Xl.Pi^ 


Axi • 


■ ■ xi.Ti Xo+i ■ ■ ■ xi A (f^fail 


{ ? 7 -conversion } 






(j) h Axi • 


■■Xl.Pi^ 


Axi • 


■ -Xq.Ti a (/) yf fail 



For the second case, we assume 

(f) = (j)\ O • • • O (j)m 

and we derive the outcome in Fig. 3. Since the third case is similar to the second 
case, we have omitted the proof. 

Since the fourth case is rather complex, we prove sufficient and necessity 
conditions separately. 

(<J=) For the case, a matching pair is 

\xi---xi.pEi ••• Em^ \xi---xi.Ti . 



Let 

B = discharge [{yi,Ei), . . . , (yrmEm)] Ti . 
Since discharge satisfies the property 

(Ayi ■■■ym-B) El- ■■Em = Ti , 

the matching property holds as follows: 

{p^ Xyi---ym-B}'r Xxi---xi.p El ■■■ E, 



Xxi ■ --xi.Ti . 
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4> = Xx. c El ■ ■ ■ Em Xx. dTi ■ ■ ■ Tm ] A c = d A 0 7 ^ fail 
{ definition of Af } 

4> = M\ Xx. El Xx. Ti ] o • • • o At |[ Xx. Em Xx. Tm ] A c = d A 4> ^ fail 
fail} 

0 = Af|[ Xx. El Xx. Ti ] . ■ • • . Af|[ Xx. Em Xx. Tm ] A c = d A 7 ^ fail 
{ assumption } 

yi3(j>i. 4>i = At I Xx. Ei Xx. Ti] A c = d A (j> fO'il X cf = tfi ° ° (pm 

{ induction hypothesis } 

yi3\(pi h Xx. Ei Xx. Ti A c = d A (f> ^ fail A 0 = o • • • o cpm 
{ dehnition of h } 

Vi3](pi. (f>i{Xx. Ei) =a/3ri Xx.Ti A c = d A (p ^ fail A (p = (pi o . . . o tpm 
{ property of (.) } 

3\(p. (p {Xx. c El - ■ ■ Em) =ai3-n Xx. d Ti ■ ■ ■ Tm A c = d A (p ^ fail 
{ dehnition of match } 

3\(p. (p h Xx. c El - ■ ■ Em Xx. d Ti - - - Tm A c = d 
Fig. 3. The derivation 



(=f>) Through Theorem 3, there is at most a single match (p such that 



(p h Xx. p El - - - Em Ax. Ti . 

The form of the match should he (p = {p Xyi - - - pm - B} where 

{ui Elm - - ,ym Em} B =af3ri Ti - 

Term B should be prepared by replacing some Ei with yi from Ti . Through 
the Definition l.(i), Ei contains free variables. Thus if B contains Ei, then 
(p is an illegal match. Therefore, term B should be prepared by replacing all 
occurrences of Ei with yi from Ti. This operation matches 



B = discharge [{yi,Ei), ..., {ym,Em)] Ti . ^ 

The complexity of our matching algorithm can be summarized in the follow- 
ing theorem. Let size{t) be a function to compute a size of the term t. 

size c =1 

size V =1 

size {ti ^ 2 ) = 1 + size ti -T size ^2 
size (Ax. t) = 1 + size t 

Theorem 5 (Efficiency). Let P be of class A, n be the size of term T, and m 
be the size of pattern P. The time complexity of M.[P — > r] zs 0{mfn). 

Proof. Except for the second last case, the time complexity of Ad is straightfor- 
wardly linear in the size of the pattern. For the second last case, the function 
discharge traverses the term and the function replace checks for each argument 
Ei. Since equality check in replace needs 0(m), that replace costs O(m^). Travers- 
ing cost of discharge is 0(n). Therefore, discharge costs 0{mfn). □ 
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Since m is quite small and bounded and patterns are much smaller than terms 
in practice, the algorithm is almost 0(n). For fixed patterns, the algorithm is 
0(n). 

5 Application to Program Transformation 

Class A covers a wider class of patterns than Miller’s higher-order patterns as 
we saw in fusion transformation in Section 1 and Section 2. In this section, we 
demonstrate how our matching algorithm can be useful in mechanizing tupling 
transformation . 

Tupling [15] is program transformation where several results are returned 
from a single traversal of a data structure. For example, a function for computing 
the average of a list 

average 1 xs = sum xs / length xs 

is transformed into 

average2 xs = s/1 

where (s,l) = sumLength xs 

where s stores the summation and 1 stores the length of the list xs. 

The definition of sumLength is defined as 

sumLength [] = (0, 0) 
sumLength (x:xs) = (x + s, 1+1) 
where (s,l) = sumLength xs 

which is derived as follows. The base case is trivial. 

sumLength [] 

= { spec, of sumLength } 

(sum [] , length [] ) 

= { unfolding sum and length } 

( 0 , 0 ) 

The recursive case of sumLength is derived by 

sumLength (x:xs) 

= { spec, of sumLength } 

(sum (x:xs), length (x:xs)) 

= { unfolding sum and length } 

(x + sum xs , 1 + length xs) 

= { introducing new function p } 
p X (sum xs) (length xs) 

= { introducing new function p’ 

s.t. p’ = \x (y,z) -> p X y z } 
p’ X (sumLength xs) 
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In fact, finding p is a matching problem 

Xxxs.p X {sum xs) {length xs) ^ (x -I- sum xs, 1 -I- length xs) , 
which is resolved with our matching algorithm and the substitution 

{p Xyi j/2 V 3 - {yi +2/2,1 + 2/3)} 

can be automatically obtained. Substituting this into the definition of p ’ , we 
obtain the definition of sumLength as 

sumLength (x : xs ) 

= (\yl (y2,y3) -> (yl+y2 , l+y3) ) x (sumLength xs) 

As another example, to avoid repeated evaluations where a function generates 
several identical calls to itself, function fib defined as 

fib 0 =1 

fib 1 =1 

fib (n+2) = fib (n+1) + fib n 
is transformed into 

fastfib n = V where (_,v) = fibt n 
fibt 0 = (1,1) 

fibt (n+1) = (u+v,u) where (u,v) = fibt n 
The derivation is reduced into a matching problem for matching pair 

Xn.p {fib n) {fib {n + 1)) ^ An. {fib (n + 1) + fib n, fib {n + 1)) , 
which is resolved with the following match. 

{p 1 -+ Xxy. {y + x,y)} 

6 Related Work and Discussion 

Higher-order matching problems in general are complicated to apply its pat- 
terns to program transformation, since second-order matching is nondeterminis- 
tic, third- or fourth-order matching is infinite, and a part of more than fifth-order 
matching is undecidable. For time complexity, higher-order matching in general 
is expensive; even second-order matching algorithm is NP-complete [7]. Its im- 
plementations are also expensive [1, 16]. 

To generate desirable higher-order matching, a classical approach is to re- 
strict the form of patterns. For example, under some restrictions, possibly un- 
decidable fifth-order matching is decidable [8], and infinite third-order matches 
are finite [2]. There are many research on time complexity of restricted patterns. 
Second-order pure matching (even unification) with a bounded number of vari- 
ables is PTIME [17]. Hirata, Yamada and Harao [18] studied the complexity 
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of various second-order matching problems. According to their classification, a 
pattern in class A is a predicate, i.e., any arguments of free variables have no func- 
tion variables. The matching problem of a predicate is polynomial if it is binary 
function-free, i.e., any function variables are at most 2-ary and have no func- 
tion constants. Linear context matching, a restricted form of linear higher-order 
matching, is O(n^) [19]. It solves the problem through dynamic programming 
with a table of size O(n^) building from the bottom up. 

Pattern matching play an important role in program transformations. Many 
systems use first-order patterns [20-22] and most of these use first-order match- 
ing [14,23-25]. Exceptions are MAG [26], KORSO [3], and TrafoLa [13]; they 
use higher-order matching, which enables program transformation to be concisely 
specified, and makes transformation more abstract and more reusable. To make 
it VHVs, we restricted class of patterns, and, therefore, the matching algorithm 
for them is deterministic. As a result, many patterns are excluded. For exam- 
ple, One of the matching algorithms used in MAG is one-step matching [2, 27] 
which returns at least complete second-order match for arbitrary polymorphi- 
cally second-order patterns; our matching algorithm covers only a restricted class 
of polymorphic second-order patterns in class A. Nevertheless, for descriptive 
power of patterns, our restriction is not restrictive for program transformation. 
Glass A is a simple and natural extension of Miller’s higher-order patterns [9], 
which has a single most-general unifier. As we saw in the previous section, pat- 
terns in this class cover wide class of patterns. It enabled the fusion law to be 
concisely described, which plays important roles in program transformations. 

Gonsider the extension of class A. Patterns in class A are not sufficient for 
T>Ti.Vs; many deterministic higher-order patterns are not included in class A 
such as a non-linear pattern Xx.p {p x), a pattern where the argument of free 
variable contains free variables Xx.p {c x q), & pattern where one argument of 

free variable contains the other argument for subterms Xx.p (c x) (ex x), and 

a pattern where the argument of free variable is A-abstraction Xx.p {Xy.c y x), 
we have not specified the syntactical class of patterns useful in program trans- 
formation that is easy to understand and whose matching algorithm is efficient. 
Gan we use patterns in class A as extension of Miller’s patterns in the context 
of unification? In the context of unification, patterns in class A are not deter- 
ministic. For example, given terms Xxy.p (c x) (c y) and Xxy. c {q y x) from a 
class A, there are at least three most-general unifiers 

{ pi-^ Xxy. X, qi-^ Xxy. y } , 

{ p 1 -^ Xx y. y, q 1 -^ Xx y. X } , and 

{ p Xx y. c {r X y), q Xy x.r {c x) {c y)} . 

7 Conclusion 

We proposed class A for VHVs that has at most a single higher-order match. 
Our restriction on patterns made our matching algorithm fast; given a fixed 
pattern, the time complexity of our deterministic matching algorithm is linear 
for the size of the term being matched. 
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There is a trade-off between completeness and efficiency in the matching 
algorithm. Since pattern types are statically distinguished in program transfor- 
mation to some extent, we might want to choose an algorithm for each patterns. 
As we saw in Section 5, class A cover a wide class of patterns often used in 
important parts of program transformation. 

Our main idea with UHV was the deterministic choice of discharging, where 
the higher-order matching was boiled down to a first-order problem. It is our 
hope that our approach can provide a new and effective way of incorporating 
higher-order patterns into functional languages [13]. 
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Abstract. Starting from a continuation-based interpreter for a sim- 
ple logic programming language, propositional Prolog with cut, we de- 
rive the corresponding logic engine in the form of an abstract machine. 
The derivation originates in previous work (our article at PPDP 2003) 
where it was applied to the lambda-calculus. The key transformation 
here is Reynolds’s defunctionalization that transforms a tail-recursive, 
continuation-passing interpreter into a transition system, i.e., an abstract 
machine. Similar denotational and operational semantics were studied by 
de Bruin and de Vink (their article at TAPSOFT 1989), and we compare 
their study with our derivation. Additionally, we present a direct-style 
interpreter of propositional Prolog expressed with control operators for 
delimited continuations. 



1 Introduction 

In previous work [2], we presented a derivation from interpreter to abstract ma- 
chine that makes it possible to connect known A-calculus interpreters to known 
abstract machines for the A-calculus, as well as to discover new ones. The goal 
of this work is to test this derivation on a programming language other than the 
A-calculus. Our pick here is a simple logic programming language, propositional 
Prolog with cut (Section 2). We present its abstract syntax, informal semantics, 
and computational model, which we base on success and failure continuations 
(Section 3). We then specify an interpreter for propositional Prolog in a generic 
and parameterized way that leads us to a logic engine. This logic engine is a 
transition system that we obtain by defunctionalizing the success and failure 
continuations (Section 4). We also present and analyze a direct-style interpreter 
for propositional Prolog (Appendix A). 

The abstract machines we consider are models of computation rather than 
devices for high performance, and the transformations we consider are changes 
of representation rather than optimizations. 
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Prerequisites: We expect a passing familiarity with the notions of success and 
failure continuations as well as with Standard ML and its module language. 

As for defunctionalization, it originates in Reynolds’s seminal article on def- 
initional interpreters for higher-order programming languages [27]. The point of 
defunctionalization is to transform a higher-order program into a first-order pro- 
gram by replacing its function types by sum types. Before defunctionalization, 
the inhabitants of each function type are instances of anonymous A-abstractions. 
Defunctionalizing a program amounts to enumerating these A-abstractions in a 
sum type: each function introduction (i.e., A-abstraction) is replaced by the corre- 
sponding constructor holding the values of the free variables of this A-abstraction, 
and each function elimination (i.e., application) is replaced by a case dispatch. 
After defunctionalization, the inhabitants of each function type are represented 
by elements of a corresponding sum type. 

Danvy and Nielsen’s study of defunctionalization contains many examples [14], 
but to make the present article self-contained, let us consider two concrete cases. 

1.1 A Simple Example of Defunctionalization 

The following (trivial) program is higher-order because of the auxiliary function 
aux, which is passed a function of type int -> int as argument: 

(* aux : int * (int -> int) -> int *) 
fun aux (x, f) 

= (f 10) + (f x) 

(* main : int * int * int -> int *) 
fun main (a, b, c) 

= (aux (a, fn x => x + b)) * (aux (c, fn x => x * x)) 

The inhabitants of the function space int -> int are instances of the two anony- 
mous A-abstractions declared in main, fn x => x + b and fn x => x * x. The 
first one has one free variable (b, of type int), and the second one is closed, i.e., 
it has no free variables. 

To defunctionalize this program, we enumerate these A-abstractions in a sum 
type lam, and we define the corresponding apply function to interpret each of 
the summands: 

datatype lam = LAMl of int 
I LAM2 

(* apply_lam : lam * int -> int *) 
fun apply_lam (LAMl b, x) 

= X + b 

I apply_lam (LAM2, x) 

= X * X 

In the defunctionalized program, each A-abstraction is replaced by the corre- 
sponding constructor, and each application is replaced by a call to the apply 
function: 
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(* aux : int * lam -> int *) 
fun aux (x, f) 

= (apply_lam (f, 10)) + (apply_lam (f, x) ) 

(* main : int * int * int -> int *) 
fun main (a, b, c) 

= (aux (a, LAMl b) ) * (aux (c, LAM2)) 

The resulting program is first order. 



1.2 A More Advanced Example: The Factorial Function 

Let us defunctionalize the following continuation-passing version of the factorial 
function: 

(* fac_c : int * (int -> ’a) -> ’a *) 
fun fac_c (0, k) 

= k 1 

I fac_c (n, k) 

= fac_c (n - 1, fn V => k (n * v) ) 

(* main : int -> int *) 
fun main n 

= fac_c (n, fn v => v) 

We consider the whole program (i.e., both main and fac_c). Therefore the poly- 
morphic type ’a, i.e., the domain of answers, is instantiated to int. The candidate 
function space for defunctionalization is that of the continuation, int -> int. Its 
inhabitants are instances of two A-abstractions: the initial continuation in main 
with no free variables, and the intermediate continuation in the induction case of 
fac_c with two free variables: n and k. The corresponding data type has therefore 
two constructors: 

datatype cont = CONTO 

I CONTI of int * cont 

(* apply_cont : cont * int -> int *) 
fun apply_cont (CONTO, v) 

= V 

I apply_cont (CONTI (n, k) , v) 

= apply_cont (k, n * v) 

Correspondingly, the apply function associated to the data type interprets each 
of these constructors according to the initial continuation and the intermediate 
continuation. 

We observe that cont is isomorphic to the data type of lists of integers. We 
therefore adopt this simpler representation of defunctionalized continuations: 
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type cent = int list 

(* apply_cont : cent * int -> int *) 
fun apply_cont (nil, v) 

= V 

I apply_cont (n : : k, v) 

= apply_cont (k, n * v) 

In the defunctionalized program, the continuations are replaced by the con- 
structors, and the applications of the continuations are replaced by a call to 
apply _cont: 

(* fac_c : int * cent -> int *) 
fun fac_c (0, k) 

= apply_cont (k, 1) 

I fac_c (n, k) 

= fac_c (n - 1, n :: k) 

(* main : int -> int *) 
fun main n 

= fac_c (n, nil) 

The resulting program is first-order, all its calls are tail calls, and all computa- 
tions in the actual parameters are elementary. It is therefore a transition system 
in the sense of automata and formal languages [23]. Both main and fac_c, together 
with their actual parameters, form configurations and their ML definitions spec- 
ify a transition relation, as expressed in the following table. The top transition 
specifies the initial state and the bottom transition specifies the terminating con- 
figurations. The machine consists of two mutually recursive transition functions; 
the first one operates over pairs of integers, and the second one operates over a 
stack of integers and an integer: 



n 




(n, 


fac 


(0, k)fac 




(fc, 


1) app 


(n, k)fac 




(n 


- 1, n :: k)fac 


{n :: k, v)app 




(fc, 


n X v)app 


(jlil-, v) app 




V 





Accordingly, the result of defunctionalizing a continuation-passing interpreter is 
also a transition system, i.e., an abstract machine in the sense of automata and 
formal languages [23]. We used this property in our work on the A-calculus [2], 
and we use it here for propositional Prolog. 
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2 Propositional Prolog 

The abstract syntax of propositional Prolog reads as follows: 

structure Source 
= struct 

type ide = string 
datatype atom = IDE of ide 

I OR of goal * goal 
I CUT 
I FAIL 

withtype goal = atom list 
type clause = ide * goal 

datatype program = PROGRAM of clause list 
datatype top_level_goal = GOAL of goal 
end 

A program consists of a list of clauses. A clause consists of an identifier (the 
head of the clause) and a goal (the body of the clause). A goal is a list of atoms; 
an empty list represents the logical value ‘true’ and a non-empty list of atoms 
represents their conjunction. Each atom is either an identifier, the disjunction 
of two goals, the cut operator, or the fail operator. 

The intuitive semantics of the language is standard. Given a Prolog program 
and a goal, we try to verify whether the goal follows from the program in the 
sense of propositional logic, i.e., in terms of logic programming, whether the SLD- 
resolution algorithm for this goal and this program stops with the empty clause. 
If it does, then the answer is positive; if it stops with one or more subgoals still 
waiting resolution, then the answer is negative. Here the unification algorithm 
consists in looking up the clause with a specified head in the program. 

An atom can be a disjunction of two goals, and therefore if a chosen body does 
not lead to the positive answer, the other disjunct is tried, using backtracking. 
Backtracking can also be used to find all possible solutions in the resolution tree, 
which in case of propositional Prolog amounts to counting the positive answers. 
Two operators provide additional control over the traversal of the resolution 
tree: the cut operator removes some of the potential paths and the fail operator 
makes the current goal unsatisfiable, which triggers backtracking. 

3 A Generic Interpreter for Propositional Prolog 

To account for the backtracking necessary to implement resolution, we use suc- 
cess and failure continuations [13]. A failure continuation is a parameter less 
function (i.e., a thunk) yielding a final answer. A success continuation maps a 
failure continuation to a final answer. The initial success continuation is applied 
if a solution has been found. The initial failure continuation is applied if no so- 
lution has been found. In addition, to account for the cut operator, we pass a 
cut continuation, i.e., a cached failure continuation. As usual with continuations, 
the domain of answers is left unspecified. 
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3.1 A Generic Notion of Answers and Results 

We specify answers with an ML signature. The type of answers comes together 
with an initial success continuation and an initial failure continuation. The sig- 
nature also declares a type of results and an extraction function mapping a 
(generic) answer to a (specific) result. 

signature ANSWER 
= sig 

type answer 

val sc_init : (unit -> answer) -> answer 
val fc_init : unit -> answer 

type result 

val extract : answer -> result 
end 

3.2 Specific Answers and Results 

We consider two kinds of answers: the first solution, if any, and the total number 
of solutions. 



The first solution: This notion of answer is the simplest to define. Both answer 
and result are defined as the type of booleans and extract is the identity func- 
tion. The initial success continuation ignores the failure continuation and yields 
true, whereas the initial failure continuation yields false. 

structure Answer _first : ANSWER 
= struct 

type answer = bool 
fun sc_init fc = true 
fun fc_init () = false 

type result = bool 
fun extract a = a 
end 



The number of solutions: This notion of answer is more delicate. One could 
be tempted to define answer as the type of integers, but the resulting imple- 
mentation would no longer be tail recursive^. Instead, we use an extra layer of 
continuations: We define answer as the type of functions from integers to in- 
tegers, result as the type of integers, and extract as a function triggering the 
whole resolution by applying an answer to the initial count, 0. The initial success 
continuation takes note of an intermediate success by incrementing the current 
count and activating the failure continuation. The initial failure continuation is 
passed the final count and returns it. 



^ In “fun sc_init fc = 1 + (fc ())”, the call to fc is not a tail call. 
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structure Answer_how_many : ANSWER 
= struct 

type answer = int -> int 

fun sc_init fc = (fn m => fc () (m+1)) 

fun fc_init () = (fn m => m) 

type result = int 
fun extract a = a 0 
end 

3.3 The Generic Interpreter, Semi-compositionally 

We define a generic interpreter for propositional Prolog, displayed in Figure 1, as 
a recursive descent over the source syntax, parameterized by a notion of answers, 
and implementing the following signature: 

signature INTERPRETER 
= sig 

type result 

val main : Source . top_level_goal * Source .program -> result 
end 

In run_goal, an empty list of atoms is interpreted as ‘true’, and accordingly, 
the success continuation is activated. A non-empty list of atoms is sequentially 
interpreted by run_seq by extending the success continuation; this interpretation 
singles out the last atom in a properly tail-recursive manner. An identifier is 
interpreted either by failing if it is not the head of any clause in the program, 
or by resolving the corresponding goal with the cut continuation replaced with 
the current failure continuation. The function lookup searching for a clause with 
a given head reads as follows: 

(* lookup : Source. ide * Source . clause list -> Source. goal option *) 
fun lookup (i, p) 

= let fun walk nil 
= NONE 

I walk ((i’ , g) : : p) 

= if i = i’ 
then SOME g 
else walk p 

in walk p 
end 

A disjunction of two goals is interpreted by extending the failure continuation. 
The cut operator is interpreted by replacing the failure continuation with the 
cut continuation. The fail operator is interpreted as ‘false’, and accordingly, the 
failure continuation is activated. 

This interpreter is not compositional (in the sense of denotational semantics) 
because g, in the interpretation of identifiers, does not denote a proper subpart 
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functor mkinterpreter (structure A : ANSWER) : INTERPRETER = 
struct 

open Source 

type answer = A. answer 
type result = A. result 
type fcont = unit -> answer 
type scont = fcont -> answer 
type ccont = fcont 

(* run_goal : goal * clause list * scont * fcont * ccont -> answer 
fun run_goal (nil, p, sc, fc, cc) 

= sc fc 

I run_goal (a :: g, p, sc, fc, cc) 

= run_seq (a, g, p, sc, fc, cc) 

(* run_seq : atom * goal * clause list * scont * fcont * ccont *) 
(* -> answer *) 

and run_seq (a, nil, p, sc, fc, cc) 

= run_atom (a, p, sc, fc, cc) 

I run_seq (a, a’ : : g, p, sc, fc, cc) 

= run_atom (a, p, fn fc’ => run_seq (a’, g, p, sc, fc’, cc) , fc, 

(* run_atom : atom * clause list * scont * fcont * ccont -> answer 
and run_atom (IDE i, p, sc, fc, cc) 

= (case lookup (i, p) 
of NONE 

=> fc 0 
I (SOME g) 

=> run_goal (g, p, sc, fc, fc)) 

I run_atom (OR (gl, g2) , p, sc, fc, cc) 

= run_goal (gl, p, sc, fn () => run_goal (g2, p, sc, fc, cc) , cc 
I run_atom (CUT, p, sc, fc, cc) 

= sc cc 

I run_atom (FAIL, p, sc, fc, cc) 

= fc 0 

(* main : top_level_goal * program -> result *) 
fun main (GOAL g, PROGRAM p) 

= let val a = run_goal (g, p, A.sc_init, A.fc_init, A.fc_init) 
in A. extract a 
end 

end 



Fig. 1. A generic interpreter for propositional Prolog 
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of the denotation of 1. The interpreter, however, is semi-compositional in Jones’s 
sense [19,20], i.e., g denotes a proper subpart of the source program. (To make 
the interpreter compositional, one can follow the tradition of denotational se- 
mantics and use an environment mapping an identifier to a function that either 
evaluates the goal denoted by the identifier or calls the failure continuation. The 
environment is threaded in the interpreter instead of the program. The resulting 
ML interpreter represents the valuation function of a denotational semantics of 
propositional Prolog.) 

3.4 Specific Interpreters 

A specific interpreter computing the first solution: A specific interpreter 
computing the first solution, if any, is obtained by instantiating mkinterpreter 
with the corresponding notion of answers: 

structure Prolog_first = mkinterpreter (structure A = Answer_f irst) 

A specific interpreter computing the number of solutions: A specific 
interpreter computing the number of solutions is also obtained by instantiating 
mkinterpreter with the corresponding notion of answers: 

structure Prolog_how_many = mkinterpreter (structure A = Answer_how_many) 

Appendix A contains a direct-style counterpart of the interpreter (uncurried 
and without cut) computing the number of solutions. 

4 Two Abstract Machines for Propositional Prolog 

We successively consider each of the specific Prolog interpreters of Section 3.4 
and we defunctionalize their continuations. As already illustrated in Section 1 
with the factorial program, in each case, the result is an abstract machine. Indeed 
the interpreters are in continuation-passing style, and thus: 

— all their calls are tail calls, and therefore they can run iteratively; and 

— all their subcomputations (i.e., the computation of their actual parameters) 
are elementary. 

In both cases the types of the defunctionalized success and failure continua- 
tions read as follows: 

datatype scont = SCDNTO 

I SCDNTl of atom * goal * clause list * scont * ccont 
and fcont = FCONTO 

I FCONTl of goal * clause list * scont * fcont * ccont 
withtype ccont = fcont 

As in Section 1.2, since both data types are isomorphic to the data type of lists, 
we represent them as such when presenting the abstract machines. 
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• Atoms, goals and programs: 

a ::= IDEi | 0R(sr, gg) | CUT | FAIL 
g ::= a* 

p ■■■■= (i, g)* 

• Control stacks: 

sc ::= nil \ (a, g, p, cc) :: sc 
fc ::= nil j {g, p, sc, cc) :: fc 
cc ::= fc 

• Initial transition, transition rules and final transition: 







(s- p) 




{g, p, 


nil, nil, nil) goal 


{nil, p 


, (a, g, p', cc') :: sc, fc. 


goal 




{a, g, 


p', sc, fc, cc')seq 




{a :: g, p, sc, fc. 


goal 




{a, g, 


p, SC, fc, Cc)seq 




{a, nil, p, sc, fc 


cc) seq 




{a, P, 


^C, fc, cc) atom 




{a, a' :: g, p, sc, fc 


cc) seq 




{a, p, 


(a', g, p, cc) :: sc, fc, cc)atom 




(IDE i, p, sc, fc. 


^^) atom 




{g, p, 


•^C, fc, fc) goal 










if lookup {i) succeeds with g 


(IDE i, p, sc, (g, p, sc' , cc') :: fc, 


atom 




{g, p' 


, sc', fc, Cc')goal 










if lookup {i) fails 




{0R{gi, g 2 ), p, sc, fc. 


atom 




{gi, % 


<, SC, {g2, p, sc, cc) :: fc, cc)g^al 


(CUT, p, 


(a, g, p', cc') :: sc, fc. 


cc) atom 




{a, g, 


p', sc, fc, cc')seq 


(FAIL, p, sc, {g, p' , sc' , cc') :: fc. 


cc) atom 




{g, p' 


, sc', fc, Cc')goal 




{nil, p, nil, fc. 


cc) goal 




true 






(IDE i, p, sc, nil. 


cc) atom 




false. 


if lookup (^) fails 




(FAIL, p, sc, nil. 


cc) atom 




false 






(CUT, p, nil, fc. 


cc) atom 




true 





Fig. 2. An abstract machine computing the first solution 



The first solution: The abstract machine is defined as the transition system 
shown in Figure 2. The top part specifies the initial state and the bottom part 
specifies the terminating configurations. The machine consists of three mutually 
recursive transition functions, two of which operate over a quintuple and one over 
a six-element tuple. The quintuple consists of the goal, the program, the (de- 
functionalized) success continuation, the (defunctionalized) failure continuation 
and the cut continuation (a register caching a previous failure continuation). The 
six-element tuple additionally has the first atom of the goal as its first element. 
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• Atoms, goals and programs: 

a ::= IDEi | 0 R(sr, gg) | CUT | FAIL 
g ::= a* 

p ■■■■= (i, g)* 



• Control stacks: 



sc ::= nil \ (a, g, p, cc) :: sc 
fc ::= nil \ {g^ p, sc, cc) :: fc 
cc ::= fc 

• Initial transition, transition rules and final transition: 









(s- p) 




{g, p, 


nil, nil, nil 


; goal 


{nil, p 


, nil, {g, p' , sc, cc') :: fc, 


cc 


, th) gQQ^l 




{g, p', 


sc, fc, cc' , 


~\~ ^) goal 


{nil, 


P, (a, g, p', cc') :: sc, fc, 


cc 


, th) gQf^l 




(a, g, 


p' , sc, fc, cc', m)seq 




{a :: g, p, sc, fc. 


cc 


, th) gQQ^l 




(a, g. 


p, SC, fc, cc 


, Vn) seq 




{a, nil, p, sc, fc 


, cc, m)seq 




(a, p. 


^^1 /C) ^^1 atom 




{a, a' :: g, p, sc, fc 


, CC, m)seq 




(a, p. 


(a', g, p, cc 


) :: sc, fc, cc, m) atom 




(IDE i, p, sc, fc. 


CC, 


f^) atom 




{g, p, 


sc, fc, fc, m)goal 












if lookup {i) succeeds with g 


(IDE i, p. 


, sc, {g, p, sc', cc') :: fc, 


cc. 


t^) atom 




{g, p', 


sc' , fc, cc' . 


1 ‘^) goal 












if lookup (2) fails 






{0R{gi, g 2 ), p, sc, fc, 


cc. 


t^) atom 




(gi,p 


, sc, (5a, p. 


SC, cc) :: fc, cc, m) g^al 


(CUT, 1 


5 , (a, g, p', cc') :: sc, fc, 


cc. 


tn) atom 




(a, g. 


p' , sc, fc, cc' , m)seq 


(CUT, p, 


nil, {g, p' , sc, cc') :: fc. 


cc. 


'tn) atom 




{g, p', 


SC, fc, cc' , 


m + l)goal 


(FAIL, p, 


{g, p', sc', cc') :: fc, 


cc. 


f^) atom 




{g, p', 


sc' , fc, cc' . 


1 goal 




{nil, p, nil, nil. 


cc 


, th) gQf^l 




m + 1 








(FAIL, p, sc, nil. 


cc. 


'tn) atom 




m 








(CUT, p, nil, nil. 


cc. 


t^) atom 




m + 1 








(IDE i, p, sc, nil. 


cc. 


'tn) atom 




m, if 


lookup (i) fails 



Fig. 3. An abstract machine computing the number of solutions 



The number of solutions: This abstract machine is displayed in Figure 3 and 
is similar to the previous one, but operates over a six- and seven-element tuples. 
The extra component is the counter. 

Both machines are deterministic because they were derived from (determin- 
istic) functions. 
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5 Related Work and Conclusion 

In previous work [2, 3, 10], we presented a derivation from interpreter to abstract 
machine, and we were curious to see it applied to something else than a func- 
tional programming language. The present paper reports its application to a logic 
programming language, propositional Prolog. In its entirety, the derivation con- 
sists of closure conversion, transformation into continuation-passing style (CPS), 
and defunctionalization. Closure conversion ensures that any higher-order val- 
ues are made first-order^. The CPS transformation makes the flow of control of 
the interpreter manifest as a continuation. Defunctionalization materializes the 
flow of control as a first-order data structure. In the present case, propositional 
Prolog is a first-order language and the interpreter we consider is already in 
continuation-passing style (cf. Appendix A) . Therefore the derivation reduces to 
defunctionalization. The result is a simple logic engine, i.e., mutually recursive 
and first-order transition functions. It was derived, not invented, and so, for 
example, its two stacks arise as defunctionalized continuations. Similarly, it is 
properly tail recursive since the interpreter is already properly tail recursive. 

Since the correctness of defunctionalization has been established [5,26], the 
correctness of the logic engine is a corollary of the correctness of the original 
interpreter. 

Prolog has both been specified and formalized functionally. For example, 
Carlsson has shown how to implement Prolog in a functional language [7]. 
Continuation-based semantics of Prolog have been studied by de Bruin and de 
Vink [15] as well as by Nicholson and Foo [25]. Our closest related work is de 
Bruin and de Vink’s continuation semantics for Prolog with cut: 

— de Bruin and de Vink present a denotational semantics with success and 
failure continuations; their semantics is (of course) compositional, and com- 
parable to the compositional interpreter outlined in Section 3.3. The only 
difference is that their success continuations expect both a failure continua- 
tion and a cut continuation, whereas our success continuations expect only 
a failure continuation. Analyzing the control flow of the corresponding in- 
terpreter, we have observed that the cut continuation is the same at the 
definition point and at the use point of a success continuation. Therefore, 
there is actually no need to pass cut continuations to success continuations. 

— de Bruin and de Vink also present an operational semantics, and prove it 
equivalent to their denotational semantics. In contrast, we defunctionalized 
the interpreter corresponding to a denotational semantics into an interpreter 
corresponding to an operational semantics. We also “refunctionalized” the 
interpreter corresponding to de Bruin and de Vink’s operational semantics, 
and we observed that in the resulting interpreter (which corresponds to a 
denotational semantics), success continuations are not passed cut continua- 
tions. 

Designing abstract machines is a favorite among functional programmers [16] . 
Unsurprisingly, this is also the case among logic programmers, for example, with 
^ Closures, for example, are used to implement higher-order logic programming [8]. 
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Warren’s abstract machine [4], which incidentally is more of a device for high 
performance than a model of computation. Just as unsurprisingly, functional 
programmers use functional programming languages as their meta-language and 
logic programmers use logic programming languages as their meta-language. 
For example, Kursawe showed how to “invent” Prolog machines out of logic- 
programming considerations [22]. The goal of our work here was more modest: 
we simply aimed to test an interpreter-to-abstract-machine derivation that works 
well for the A-calculus. The logic engine we obtained is basic but plausible. 
Its chief illustrative virtue is to show that the representation of a denotational 
semantics can be mechanically defunctionalized into the representation of an 
operational semantics (and, actually, vice versa). It also shows that proper tail 
recursion and the two control stacks did not need to be invented - they were 
already present in the original interpreter. 

An alternative to deriving an abstract machine from an interpreter is to fac- 
tor this interpreter into a compiler and a virtual machine, using, e.g.. Wand’s 
combinator-based compiler derivation [29], Jprring and Scherlis’s staging trans- 
formations [21], Hannan’s pass-separation approach [18], or more generally the 
binding-time separation techniques of partial evaluation [20,24]. We are cur- 
rently experimenting with a such a factorization to stage our Prolog interpreter 
into a byte-code compiler and a virtual machine executing this byte code [1] . 
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A A Direct-Style Interpreter for Prolog 

The interpreter of Section 3 is in continuation-passing style to account for 
the backtracking necessary to implement resolution. Therefore, our derivation 
method which in its entirety consists of three steps - closure conversion, CPS 
transformation, and defunctionalization [2] - was reduced to only the last step. 
Less natural, but making the derivation closer to its original specification, would 
be to start it with an interpreter in direct style. The failure continuation could be 
eliminated by transforming the interpreter into direct style [9] . The success con- 
tinuation, however, would remain. Because it is used non tail-recursively in the 
clause for disjunctions, it is what is technically called a delimited continuation 
(in contrast to the usual unlimited continuations of denotational semantics [28]). 
Transforming the interpreter into direct style requires control operators for de- 
limited continuations that are compatible with continuation-passing style, e.g., 
shift and reset [11, 12, 17]. 

Figure 4 presents such a direct-style interpreter for Propositional Prolog with- 
out cut, counting the number of solutions. GPS-transforming this interpreter 
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structure Prolog_how_many_DS : INTERPRETER 
= struct 

open Source 
type result = int 

(* run_goal : goal * clause list * int -> int *) 
fun run_goal (nil, p, m) 

= m 

I run_goal (a : : g, p, m) 

= run_seq (a, g, p, m) 

(* run_seq : atom * goal * clause list * int -> int *) 
and run_seq (a, nil, p, m) 

= run_atom (a, p, m) 

I run_seq (a, a’ :: g, p, m) 

= let val m’ = run_atom (a, p, m) 
in run_seq (a’, g, p, m’) 
end 

(* run_atom : atom * clause list * int -> int *) 
and run_atom (FAIL, p, m) 

= shift (fn sc => m) 

I run_atom (IDE i, p, m) 

= (case lookup (i, p) 
of NONE 

=> shift (fn sc => m) 

I (SOME g) 

=> run_goal (g, p, m) ) 

I run_atom (OR (gl, g2) , p, m) 

= shift (fn sc => let val m’ = sc (run_goal (gl , p, m) ) 
in sc (run_goal (g2, p, m’)) 
end) 

(* main : top_level_goal * program -> int *) 
fun main (GOAL g, PROGRAM p) 

= reset (fn () => let val m = run_goal (g, p, 0) 
in m + 1 
end) 

end 



Fig. 4. A direct-style interpreter for propositional Prolog 



once makes the success continuation appear. CPS-transforming the result makes 
the failure continuation appear, and yields the interpreter of Section 3.4 (minus 
cut). Defunctionalizing this interpreter yields the abstract machine of Section 4 
(minus cut). 

The reset control operator delimits control. Any subsequent use of the shift 
control operator will capture a delimited continuation that can be composed; 
this delimited continuation is the success continuation. Conjunction, in run_seq. 
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is implemented by function composition. Failure, in run_atom, is implemented 
by capturing the current success continuation and not applying it. Disjunction, 
in run_atom, is implemented by capturing the current success continuation and 
applying it twice. This interpreter is properly tail recursive, which is achieved by 
the two functions run_goal and run_seq that single out the last atom in a goal. 

The interpreter is a new example of nondeterministic programming in direct 
style with control operators for the first level of the CPS hierarchy [6,11]. In 
order to interpret the cut operator we would have to use the control operators 
of the second level, shift 2 and reset 2 . 
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Abstract. We identify a restricted class of terms of the lambda calculus, 
here called weak linear, that includes the linear lambda-terms keeping 
their good properties of strong normalization, non-duplicating reductions 
and typability in polynomial time. The advantage of this class over the 
linear lambda-calculus is the possibility of transforming general terms 
into weak linear terms with the same normal form. We present such 
transformation and prove its correctness by showing that it preserves 
normal forms. 



1 Introduction 

Linear programs are simple. Concerning implementation issues, for linear pro- 
grams one may safely inline the term bound to any variable, or safely update 
structures in place. Every linear term in the A-calculus is /3-strongly normal- 
izing (i.e., there is no infinite /3-reduction sequence starting from M), every 
/3-reduction of a linear term is non-duplicating and every closed linear term is 
typable in the simple type system [10], thus it is typable in polynomial time. 

The language we use in this paper is the lambda-calculus, because it can be 
viewed simultaneously as a simple programming language in which computations 
can be described, and as a mathematical object about which rigorous statements 
can be proved. Thus linear programs are modeled by linear A-terms: A-terms M 
such that for each subterm Xx.P of M, x occurs free in P at most once. 

Consider the following question: is there a way of simulating the standard A- 
calculus by the linear A-calculus? If simulation means transforming the original 
standard term into a linear term with the same normal form then it is not 
possible, in general, to define such transformation. This is shown by the next 
simple example: it is not possible to transform the term (in normal form) Xx.xx 
into a linear term with the same normal form. This happens for any non-linear 
normal form. 

In this paper we address the following problem: is there a restricted class of 
A-terms, with the same nice properties of the linear A-calculus and such that we 
can simulate the standard A-calculus by terms of that class? 

We show that there is a restriction with these properties, which we here 
call the weak linear X-ealculus. A A-term M is weak linear if in any reduction 
sequence of M, when there is a contraction of a /3-redex (Xx.P)Q, then x occurs 
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free in P at most once, i.e., when a function Xx.P is applied, its formal parameter 
X must occur at most once in the function body. For example the term Xx.xx 
is weak linear because it is a non-linear A-abstraction which is never applied. 
The term (Xx.xx)I is not weak linear because it has a redex where the function 
is not linear. For weak linear terms, only functions that can be applied to an 
argument in the reduction process are required to be linear. 

Notice that our definition does not refer only to /3-redexes {Xx.P)Q that are 
subterms of the original term M, but to abstractions Xx.P that are going to 
be the function part of a /3-redex in the reduction of M . For example the term 
M = {{Xx.x){Xx.xx))k is not weak linear although it does not have any subterm 
of the form (Xx.P)Q with x occurring more than once in P. The problem is that 
there is a redex of this form (in this case, (Xx.xx)k), in a reduction sequence 
from M. 

The main contributions of this paper are the following: 

— A restricted class of A-terms, here called the weak linear X-ealculus with the 
same basic properties of the linear A-calculus. Here we show that weak linear 
terms are strong normalizing and typable in polynomial time. 

— A transformation of general terms into weak linear terms preserving normal 
forms. To deal with transformation of redexes which will appear during the 
reduction process (the virtual redexes) our transformation uses legal paths, 
[3,4], because this notion provides a formal characterization of the intuitive 
notion of virtual redex. This contribution is also significant for the method- 
ology it develops. What we set up is a new use of legal paths for complex 
term transformation. 

Let us quickly review the existing literature on the question. A linearization 
of the A-calculus was made by Kfoury [12]. He embedded the A-calculus into 
a larger calculus, denoted with a new notion of reduction, denoted In 
the new calculus A^, in every function application, an argument is used at most 
once. He also defined the notion of contraction of a term in the new calculus, 
giving a A-term. This last notion gives a way of transforming terms in the new 
calculus into terms of the A-calculus, however, it was not presented a direct 
definition of a transformation of A-terms into terms of the new calculus. The 
relation between the two calculus was made indirectly saying that the well- 
formed terms of the new calculus are the ones for which there is a contraction 
in the A-calculus. Our algorithm is defined directly as a transformation from 
A-terms to weak linear terms and simulating the A-calculus by a subset of the 
A-calculus and not by a non-standard calculus. The problem was also discussed 
in [8] where it was established a relation, not a transformation, between terms 
typable in an intersection type system and linear terms. Types played a central 
role is the definition of this relation and, because the mapping was on the linear 
A-calculus, /3-normal forms were not preserved. 

The type system used in our paper was used (with minor differences) before in 
[13] and [1], as a restricted form of intersection type inference for terms resulting 
from a simplification process of arbitrary terms. Finally we remark that our 
definition of linear term follows [12], but some people call this class of terms 
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affine, and use the word linear for terms Xx.M where x occurs free exactly once 
in M. 

In the rest of the paper we assume that the reader is familiar with the A- 
calculus. A standard reference for this area is [5]. A good survey on the applica- 
tion of A-calculus to programming language technology can be found in [6] . 

We start in Section 2 with the definition of weak linear lambda terms. In 
section 3 we present a type system and a type inference algorithm for the weak 
linear calculus. In section 4 we present a transformation from A-terms into weak 
linear A-terms, and prove that it is correct in the sense that it preserves normal 
forms. Finally we conclude and outline some future work in section 5. 



2 The Weak Linear Lambda Calculus 

We start this section by giving some brief notions on A-calculus. 

Definition 1. Let x range over an infinite set of variables. The set of X-terms, 
A is defined as: 

M,N € A::=x\ Xx.M \ MN 

As usual the set of A-terms is quotiented by a-con version. We use the usual 
notation of reduction 

(Xx.M)N ^0 M[N/x] 

As usual, FV (M) denotes the set of free variables of M. In the rest of the paper 
we assume that no variable is bound more than once, and that it is impossible 
for a variable to occur both free and bound in a term. 

Definition 2. The length of a term M is defined as follows: 

— length{x) = 1; 

— length{MN) = length{M) + length{N) + 1; 

— lengthfXx.M) = length(M) + 1. 

Definition 3 (Weak linear terms). A X-term M is weak linear iff every redex 
{Xx.P)Q, in the reduction graph of M (consisting of every reduction sequence 
from M ), is such that x occurs at most once in P. 

Definition 4. If M is strongly normalizable, the maximal length of a derivation 
from M is called the reduction depth of M, and denoted depth{M). 

Lemma 1. For weak linear X-terms, contracting a redex reduces the length of a 
term. 

Proof. The redex {{Xx.M)N) is longer than M[N/x] if x occurs free at most 
once in M. □ 

Corollary 1 (Strong normalization). If M is a weak linear X-term, then a 
/3-reduction sequence starting at M cannot have more reduction steps than the 
length of M. Hence, every weak linear X-term has a normal form. 
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3 Type Inference for the Weak Linear Lambda Calculus 

Here we present a type system that types every weak linear term. Note that 
closed linear terms are typed in the Simple Type System [11], but the same does 
not happen with weak linear terms. In this case functions which are never applied 
may not be linear. For example the term Xx.xx is weak linear and it is not typable 
in the Simple Type System. The type system described in this section, here 
called Tw type system, is based on intersection types [7]. Note that the previous 
term, Xx.xx, is typed by intersection types with type ((a ^ (3) C\ a) ^ (3. We 
use intersections only to type abstractions, and when typing applications the 
function part cannot have a domain denoted by an intersection. This is enough 
to type every weak linear term keeping the decidability of the type inference 
problem. 

3.1 A Type System for Weak Linear Terms 

Definition 5. An infinite sequence of type-variables is assumed to he given. 
Intersection types are expressions defined thus: 

1. each type-variable is a type; 

2. if a and ri . . . r„ are types (for n> 1) then (ti n • • • IT r„ ^ cr) is a type. 

In the previous definition T is assumed to be an associative, commutative and 
idempotent operator. 

Definition 6. A type environment is a finite set of pairs of the form x : r, 
where x is a term variable (called the subject^ and t is a type. 

Notation: The set of subjects of a type environment B will be called Subjects(B). 
The set of types associated to a variable x in an environment B will be called 
B{x). 

Definition 7. The Tw system is defined by: 



VAR 


{x : a} \- X : a 




ABS-I 


AU {x : T\, . . . ,x : r„} \- M : a 


ifx€FV{M) (a) 


A h Xx.M : Ti n • • • n r„ ^ (j 


ABS-K 


A'r M -.a 
A h Xx.M : T ^ a 


ifx^ FV{M) 


APR 


Ai\- M : T ^ a A 2 \~ N : t 




Ai U Ao F MN : a 





(a) If cc : Ti,. . . ,x : r„ are all and nothing but statements about x on which 
A\J {x : Ti, . . . ,x : r„} \- M : a depends. 

M : a is derivable from an environment A in the Tw type system, notation 
A\- M : cr, if and only if it is obtained using the previous rules. Note that in Tw 
intersections only appear in the ABS-I rule, thus in type derivations, intersection 
types can only appear in the types of abstractions which are not applied. 
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Example 1. In system Tw we have h {\x.xx) : (a n (a ^ /3)) ^ j3 but 
(Ax.xx)(Ax.x) is not typable. 

Lemma 2. For any term M, if A \- M : a, then Subjects(A) = FV{M). 

Proof. By a straightforward structural induction on M. □ 

Lemma 3. Let M he a weak linear X-term of the form M = {Xx.P)Q and 
M* = P[Q/x]. Let B h M* : a. Then: 

1. If X occurs free in P, then 3 b>-B' \- M : a; 

2. If X does not occur free in P, and 3 b"^t-B” \~ Q : t then 3 b' -B' \- M : a. 
Proof. 



1. By lemma 2, B = B' U B” and 

- B'UB" ^ P[Q/x]:a (1) 

where Subjects{B') = FV{P) \ {x} and Subjects{B") = FV{Q). This deriva- 
tion contains a sub-derivation of the form: 

- B”^Q: 9 (2) 

In (I), the assumption Q : 9 is only used once, since P only contains one x. 
If we replace Q hy x through (1), we get the deduction 

B' U{x : 9}h P : a (3) 

Rule (ABS) can be applied to (3) to get 

B' h Xx.P -.9^a (4) 

and then by (2) and rule (APP) we have M : a. 

2. Argue as in 1, but use the assumed-to-be-given type derivation for Q instead 

of (2). □ 

Theorem 1. Every weak linear term M is typable in system Tw 

Proof. By induction on {depth{M),length{M)), using lemma 3. □ 



3.2 A Type Inference Algorithm 

The type inference algorithm presented here is a generalization of the Hindley’s 
algorithm for Simple Types ([9], [11]). A brief sketch of a similar system was 
presented before in [13]. The main difference to the Simple Type System is that 
type declarations for the same variable in the environment may not be unique, 
and abstractions are typable even when types of their formal parameter do not 
unify. 

Definition 8. Let UNIFY he Robinson’s unification algorithm [15]. Given a A 
term M, we define the function T{M) = {F,t), where F is a type environment 
and T is a type, thus: 

1. If M = X then T{M) = ({x : a}, a) where a is a type variable. 

2. If M = Xx.N then: 

— IfT{N) = {F',t) and x ^ Subjects{F'), then T{Xx.N) = {F',a r) 
where a is a new type variable. 
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— If I{N) = {r',r) and r'{x) = {n, . . . , t„} , thenX{Xx.N) = (T'^jnlT 
• • • n r„ ^ r) . 

3. If M = M 1 M 2 then X{M) = (5'(r'i U 12)5 <S'(q;)) where: 

- X{M^) = 

-X(M2) = (T2,T2); 

— S = UNIFY{t\,T 2 a) (a is a new type variable). 

Theorem 2. 

1. X{M) = {r, a) if and only if M is typahle in system Tw- 

2. X{M) terminates in time polynomial in the size of M. 

Proof, (sketch) For the first part we must show that X{M) = {X, a) ^ M 
is typable in system Tw and B \- M : t ^ 3A,a-X{M) = {A, a). The first 
point is proved by induction on the structure of M. In the proof of the second 
point we claim that if h M : r, then there is an environment A, type a and 
substitution S such that X{M) = (A, a) and (B,t) = (SA,Sa). Our claim is 
proved by induction on the structure of M . 

The second part of the theorem follows noticing that unification is PTIME- 
complete and that the inference algorithm analyses each subterm at most once. □ 

4 Transformation into Weak Linear Terms 

Let us see what means to transform a A-term into a weak linear term. Consider 
the following example: suppose one wants to define the weak linear version of the 
term {Xxy.xy){Xz.zz){Xw.w). In this term the only variable which occurs more 
than once is 2 . Thus we must linearize {Xz.zz) to get the term (XZ 1 Z 2 .Z 1 Z 2 ). But 
(Xz.zz) will have y as an argument after one reduction step. Thus y in (Xxy.xy) 
has to be copied and we get the term: 

{Xxy.xyy){XziZ 2 .ziZ 2 ){Xw.w) 

Now, a variable which occurred once in the original term occurs twice in the 
new term, thus the linearization process has to go on, linearizing (Xxy.xyy) to 
obtain (Xxyiy 2 .xyiy 2 ). Notice that y will be replaced by Xw.w in the original 
version of the term, thus, as y was replaced by two new parameters, we have to 
duplicate (Xw.w) in the resulting term to get the final term: 

{Xxyiy2.xyiy2){XziZ2.ziZ2){Xw.w){Xw.w) 

Notice that y will be replaced by Xw.w after one reduction step. Thus the trans- 
formation algorithm has to know in advance that subterms of the form (Xx.M) 
and N are going to be the function and argument part of a redex in the future, 
i.e. {Xx.M)N is a virtual redex. To deal with this complicated issue we make use 
of legal paths. Legal paths were introduced by Asperti and Laneve [4] as a char- 
acterization based on paths of Levy’s redex families in the context of optimal 
reductions for the A-calculus. They provide a static characterization of virtual 
redexes and revealed to be quite useful for program transformation. As far as 
we know this is the first work relating the two subjects. 
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4.1 The Labeled A-Calculus and Legal Paths 

The Labeled A- Calculus. The labeled A-calculus is an extension of the A- 
calculus, proposed by Levy in [14]. In the rest of the paper, we will use x,y,z, . . . 
to range over variables, a,b,c, . . . . . . to range over labels, and ip,ip, 4>, . . . 

to range over paths. 

Definition 9. Let x range over an infinite set of variables V, and I over an 
infinite set of labels L. The set of labelled X-terms, is defined as: 

M,N ::= x' | {MNY \ {Xx.MY 

We make the same assumptions regarding free and bound variables, as in the A- 
calculus, and we also assume that all the labels in a labeled A-term are pairwise 
distinct . 

Labeled /3-reduction is the following rule (note that Iq ■ (T)*^ = 

{{Xx.mY°NY^ ^h-h- M[lo ■ N/x] 

where the label lo is the degree of the redex {{Xx.MY° N)'-^ 

Labels provide an approach to the notion of computation as a travel along 
a path. Note that every label trivially defines a path in the syntactic tree of the 
term. 

Example 2. M = {{\x.{{x^{Xy.{y^yyyYviYf{\w.{\z.{w'^{wPz’iY)'^YfY 

has the graph representation given by Figure 1. 



a 




Xx Xw 

I c \l 




y y 



Fig. 1. Labeled A-term 



Definition 10. If I is a label of an edge generated along some reduction from 
M , the path of I in M is inductively defined as follows: 

path{a) = a 

path{lil 2 ) = path{li) ■ path{l 2 ) 
path(l) = path{l) 
pathfl) = {path{l)Y 
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where ipi ■ ip 2 means concatenation of the two paths (in the following we will 
sometimes omit ■), and ip'^ is the path obtained by reversing p. 

Legal Paths. Different degrees of redexes correspond to different paths in the 
original term. Legal paths are a characterization of paths yield by degrees. Legal 
paths are obtained by suitably constraining another type of paths which are 
the well balanced paths (wbp). (All the definitions and results concerning legal 
paths, presented in this sub-section, can be found in [4].) 

Definition 11. Well balanced paths are inductively defined in the following way 
(see Figure 2): 

— (base case) The function edge of any application, is a well balanced path. 

~ (X- composition) Let ip be a wbp of type @-a; whose ending variable is bound 

to a X-node c and p be a wbp of type @-A coming into c. Then ip.(p)'^ .u is 
a wbp, where u is the argument edge of the initial node of p; 

— (@-composition)Let ip be a wbp of type ending into a node d and p be 
of type @-A leading from d to some X-node c. Then ip.p.u is a wbp, where u 
outgoes c towards its body. 

The type @-? where ? can be A, @ or a; (variable) is determined by the type of 
the node where the wbp ends. 




Fig. 2. Well balanced paths 



Example 3. The set of wbp (of the form path : type) of the A-term M of Figure 
1 is given by: 

Initial paths: 

{b : @-A, d : e : @-x, h : @-x, n : @-x,p : @-a:} 

Applying (X- composition) to the initial paths, and (©-composition) to the new 
paths we get, 

{e ■ b ■ k : @-X, d- ebk-l \ @-A} 

Again by (X- composition) and (©-composition) we get 

{n ■ kbe ■ f : ©~X,p ■ kbe - f : @-A} 
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After one more iteration 

{h ■ f ebkn • o : @-x, h • f ebkp ■ q : @-x} 



Finally 



{hfebkpq-lkbed-j : @-cc} 



Thus, the set of wbp of type @-A is given by: 



{b : @-A, e-b ■ k : @-A, d- ebk- 1 : @-A, n ■ kbe ■ f : @-A,p ■ kbe- f : @-A} 



Note that, if we imagine that bound variables (x) are explicitly connected to 
their binders (Ax), these paths are actual paths in the graph representation of 
M. 

We now present two other kinds of paths in a term needed to define legal paths. 

Definition 12. Let p be a wbp. 

— {v-cycles) Letv be the label of a variable edge. A v-cycle (overv) is a cyclic 
subpath of the form vX{Lpy@f;@(pXv where p is a wbp and if is a @-cycle. 

— {©-cycles) A ©-cycle, over an @ node with argument subterm N, is a sub- 
path if that starts and ends with the argument edge of the ©-node, and com- 
posed of subpaths internal to the argument N and v-cycles over free variables 
of N. A particular case of ©-cycle is a cycle starting from and ending to the 
argument edge p of a ©-node (the negative auxiliary port), and internal to 
the argument N of the application (i.e. not traversing variables which are 
free in N). 

Example ). The wbp h f ebkpqlkbedj of type @-x of example 3 has a x-cycle 
eXb©k p q I k©bXe and a @-cycle ©kpql k©. 

Proposition 1. Let p be a wbp with a ©-cycle ©if©. Then p can be uniquely 
decomposed as 

CiAC2@^@(C3)"AC4 

where both (2 and (3 are wbp’s. The paths C 2 and (3 are called the call and return 
paths of the ©-cycle if. The last label of Ci and the first label of C 4 are named 
the discriminants of the call and return paths, respectively. 

Definition 13. A wbp is a legal path if and only the call and return paths of 
any ©-cycle are one the reversed of the other and their discriminants are equal. 

Example 5. The wbp’s of example 3 are all legal. Notice that in the only path 
having a @-cycle h f ebkpqlkbedj, the call and return paths of the cycle are 
both b (thus one is the reversed of the other), and the discriminants are both e. 

Theorem 3. Every path yield by the degree of a redex is a legal path. 

Theorem 4. For any legal path of type @-A in a term M , there exists a degree 
I of a redex originated along some reduction of M such that path{l) = ip. 
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Example 6. Consider the labeled A-term of Figure 1. Let A' = and 

P = {\w .{\z .{w'^ {w'P . After one labeled reduction we get the A-term 
The path yield by degree ebk of the redex is ebk 

and it is the legal path of type @-A starting in the application node having A' 
as argument subterm and ending in P. Also note that e 6 fc is an actual path in 
the graph in Figure 1 when we assume that bound variables (x) are explicitly 
connected to their binders (Ax). 

4.2 Term Transformation 

Here we present a transformation from arbitrary A-terms into weak linear terms. 
We first prove some lemmas which are going to be used in the proof of the 
correctness of the transformation. 

Lemma 4. M is a strongly normalizable term, iff the set CP of legal paths of 
type @-A in M is a finite set. 

Proof. We prove the two directions separatly. 

<J= Suppose that the set of legal paths of M is not finite. By theorem 4 there is 
an infinite number of paths yield by degrees of redexes. Thus, there is an infinite 
reduction of M , which means that M is not strongly normalizable. 

Suppose that M isn’t strongly normalizable. Let us choose a reduction of M 
that doesn’t stop. That reduction will cause an infinite number of paths yield 
by degrees of redexes. Thus, by theorem 3, an infinite number of legal paths. □ 

Definition 14. Let M he a X-term, CP he the set of legal paths of M, and Si 
the paths corresponding to redexes in M . We define the chain of dependences 
between legal paths of type @-A in CP as S\ S 2 ••• Sn •• • such 
that the legal paths in Si are build by A-composition from the paths in the sets 
Si, ... , Si-i and ©-composition from the paths in Si. 

Definition 15. Let M he a X-term, and CP be the set of legal paths of M. 
The function next-nonJinear(M) returns a pair of labels (l,k), where I is the 
abstraction node where the next non linear legal path, of type @-A, in the chain 
of legal paths built from CP, ends and k is the function edge of the application 
node where it starts. Lf every legal path is linear, next-nonJinear(M) =T . 

Basically this function returns the labels which identify the next non-linear vir- 
tual redex. 

Example 7. For the A-term M in Figure 1, with the set CP, of legal paths of 
type @-A, given in example 3 the chain of legal paths is 

{b} {e • b ■ k, d • ebk ■ 1} {n • kbe • f, p ■ kbe ■ f} 

thus the result of next_nonJinear{CP) is (fc,e). 

Lemma 5. If M is a X-term and {l,k) = next-nonJinear(M) , then the only 
application node such that there is a legal path ip of type @-A ending in I is the 
application with function edge, labeled k. 
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Proof. Suppose there are legal paths ipi and ip 2 both finishing in the abstrac- 



diferent degrees h I 2 of redexes (having the abstraction labeled I as left side) 
originated along some reduction of M such that path{li) = ipi (i = 1,2). If 



plicated by some reduction previous to l\ and ? 2 - Thus, there is a non linear 
legal path previous to ipi and ip> 2 , in which case I would not be the result of 



Example 8. Consider the chain of legal paths of type @-A in example 7. We have 
next_nonJ,inear{M) = (fc, e), and the application node whose function edge is e 
is the only application node for which there is a legal path tp ending in k. 

Definition 16 (one step of the transformation). Let M he a X-term. We 
define the term C{M), that results from linearizing the next non linear abstrac- 
tion {Xx.Py of M . Let n be the number of occurrences of x in P: 



occurrence of x in P by the fresh variable Xt (i = 1, . . . ,n). 

— Ml = replacc-n{k,n, M'), where replace-n{k,n, M') is the function that re- 



places the term by ((• • • (Q^^ iV"*^) • • • )'="_/V'"")-^ (see Figure 3). 

' ^ 



Remark: Note that the labels in each copy of N are such that, if N has a label c 



tion {Xx.Py and starting in two diferent application nodes. Thus there are two 



{Xx.Py appears as the left side of two different redexes, then {Xx.Py was du- 



nextjnonJinear{M) . 



□ 




M if next-nonJineaifM) =T 
Ml otherwise 



where 

— yi,k) = nextjnonJinear{M); 

— M' = replace{l , M) , where replace{l, M) replaces the abstraction {Xx.Py 



in M by (Axi. . . . (Acc„.P*)^" • • • )*^, and P* results from replacing the 



n times 



in M, there is a label ci in the i^^ copy of N in Mi. 




p 



p* 



Fig. 3. Expansion of an abstraction 
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Example 9 . Let M be the A-term in Figure 1. The term that results from ex- 
panding the first non linear path (e ■ b ■ k) in M , C{M) is given by Figure 4. 

Definition 17 (Transformation into weak linear terms). Let M be a X- 

term, and CP the set of legal paths in M . We define the following function: 



T{M) 



M if alLlinear{M) 

T{£{M)) otherwise 



The function allJinear{M) returns true if all the legal paths of type @-A in M , 
end in a linear abstraction, and false otherwise. 




Xx 

I c 



@ 



V 



@ V 





X Xy 



\gi 





y 



y y 



Awi 

1^2 

XW2 

I I 

Xz 

\m 




W2 z 



Fig. 4. Term M, of Figure 1, after one step of transformation 



Example 10 . Let A = Xy.yy and D = Xyiy2.yiy2- Let M = (Xx.xAv) 
(Xwz.w(wz)) be the term represented in Figure 1. Let us follow the transfor- 
mation in some detail. We will omit the labels of the terms, except the ones 
needed to follow the example. We first linearize the abstraction (Xwz.w{wz))^ 
and duplicate the argument of a;® corresponding to the first non-linear abstrac- 
tion on the chain of paths in example 7, {e • b ■ k), to get the term in Figure 4. 

T(M) = T{{Xx.xA^^ A^^v){Xwi.{Xw2Z.wi{w2z))'^^)'^^) 

After one more step, linearizing A^^, we get: 

E {{Xx .xD Av){Xw\W2Z .W\{W2Z) {W2Z))) 

Now the abstractions labeled by ^2 and I in {Xw 2 .{Xz.wi{w 2 z){w 2 z)y)^^ which 
were linear, became non-linear thus, after a one more step we get: 

T {{Xx.xDAAv){Xw\ W2W3Z.W1 {w2z) {w^z))) 
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Linearizing Xz.wi{w 2 z){w 3 z) we get 

T{{Xx.xD^^ A^'^'^Vv){XwiW2W3ZiZ2-Wi{w2Zi){w3Z2))) 

The next non-linear abstraction is the copy of A labeled by / 21 , thus we get: 

T( ( Xx.xDDAvv) ( Xu>i W2W3ZiZ2-Wi(w2ZiZi)(w3Z2))) 

The abstraction (XziZ 2 -Wi('W 2 ZiZi)(w 3 Z 2 ))) becomes non-linear, thus, after a few 
more steps, we get: 

= T((Xx.xBBAvVv)(XwiW2W3ZiZ3Z2.Wi('W2ZiZ3)(lU3Z2))) 

= T((Xx.xDDDvVVv)(XwiW2W3ZiZ3Z2Z4.Wi(w2ZiZ3)(w3Z2Z4))) 

= (Xx.xDDDvVVv)(XwiW2W3ZiZ2Z3Z4.Wi(w2ZiZ2)(w3Z3Z4)) 

Now all the legal paths of type @-A are linear, thus the transformation termi- 
nates. Note that nf{M) = (vv)(vv) = nf('T(M)). As we shall prove latter, this 
happens for every term. 



4.3 Correctness 

Here we show that the transformation preserves normal forms. The proof relies 
in the next lemma, which basically, relates the legal paths of the original term 
and of the transformed term. 

Lemma 6. If C{M) = Me, let (l,k) = next-nonJinear(M) and N the subterm 
argument of the application node having k as function edge, then the set Pc of 
legal paths of Me is such that: 

1. If ip is a legal path internal to N , then cpi (i = 1 .. .n) is a legal path in the 
i*^ copy of N in Me; 

2. If p is a legal path with a ©-cycle in N (starting and ending outside N), 
then p' is a legal path with a cycle in a copy of N in Me; 

3. If p is a legal path not internal but starting and ending in N , then p' is a 
legal path starting and ending in a copy of N in Me; 

4- If p is a legal path starting /ending in N , then p' is a legal path start- 
ing/ending in a copy of N in Me, and ending /starting in the same edge; 

5. If p = ktpl is the legal path in M of type @-A ending in {Xx.P/ , then in 
Me, there are n paths of type @-A ending respectively in (Axi . . .Xn-P*/^, 
{Xx 2 ■ ■ ■ Xn-P*y^, ■ • ■ , {Xxn-P*Y’' , and starting respectively in k\,k 2 , ■ ■ ■ , kn, 
(n > 1 ); 

6. If p is a legal path in M of any type, external to N , then there is a legal path 
of the same type in Me, starting and ending in the same edges. 



Proof. The proof follows by induction on the number of recursive calls of the 
algorithm for building legal paths. This is a tedious case analysis. Details are in 
the Appendix of the full report of this paper [2] . 
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Example 11. Let M be the labeled term in Figure 1, and Me (the term obtained 
from M after one step of transformation) in Figure 4. 

Given the legal path of M, h, we have the corresponding legal paths hi and 
/i 2 in Me- This illustrates point 1 of lemma 6. 

For point 5 of the same lemma, notice that given the legal path ebk oi M, 
we have two legal paths ci bk\ and C 2 ci bki k 2 is Me- 

Theorem 5. IfT{M) = N, then N is weak linear. 

Proof. If T{M) terminates then the set of legal paths (of type @-A) in N , is a 
finite set of linear legal paths. Since only the abstraction nodes which are the 
end of a legal path appear as the left side of a redex along a reduction of N 
(that follows from theorem 3), and being all those abstractions linear, then no 
reduction starting from N duplicates arguments. Thus N is weak linear. □ 

Lemma 7. Let r be a reduction sequence from a term M using the normal order 
reduction strategy (i.e., at each step do the leftmost outermost fi -reduction). Let 
A he a j3-redex reduced in another reduction sequence of M and such that A is 
not reduced in r. Then there exists a (3-redex A' reduced in r such that 

A' = {Xx.P)A and x FV{P) 

Proof. Suppose that A is not reduced in r and that A is not erased in r (by a 
redex of the form A'). Then A must be a subterm of the normal form of M, 
which is absurd, because it is a /3-redex, thus it cannot be a subterm of a term 
in /3-normal form. □ 

Lemma 8. Lf L{M) = N , and both N and M have a normal form, then 
nf{M) = nf{N). 

Proof. Notice that the normal order reduction strategy is normalizing, i.e., if 
there is a normal form of M then it can be reached using the normal order 
strategy of reduction. Now let (Xx.P) be the abstraction labeled I, where I = 
nextjnonJinear{M), and choose the normal order reduction of M . We then have 
two cases: 

1. The expanded abstraction appears in the normal reduction sequence: 

M ^ > {Xx.P)Q [Q/x]P > nf{M) 

By lemma 6, we have 

N ^ ^ {Xxi . . .Xn.P*) Q . [Q/xi,.. .,Q/Xn]P*. 

n times 

But [Q/xi, . . . ,Q/xn]P* = [Q/x]P, thus [Q/xi, . . . ,Q/xn]P* ^ ^ nf{M). 

Thus nf{N) = nf{M). 

2. If the expanded abstraction does not appear in the normal reduction sequence 

of M then, use lemma 7 to get a similar result. □ 
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Theorem 6. IfT{M) = N, then nf{M) = nj{N). 

Proof. By induction on the number of recursive calls of T. 

— Base case : allJinear{M). Then T{M) = M in which case nf{M) is trivially 
equal to n/(iV); 

— Induction step : T (M) = T (M/), where Mi = L{M). By the induction hypoth- 
esis, nf{Mi) = nf{N), and by lemma 8 nf{Mi) = nf{M), thus nf{N) = nf{M).U 

Theorem 7. IfT{M) = N, then M is strongly normalizable. 

Proof. If T{M) terminates then the set of legal paths of N is finite. By lemma 
6, it is easy to verify that the number of legal paths in T(M) is greater or equal 
to the number of legal paths in M, thus the set of legal paths of M is finite, 
which means, by lemma 4, that M is strongly normalizable. □ 

Note that the transformation may not terminate. In every example tested, the 
non-termination of T(M) arises when the reduction of M itself may not termi- 
nate. 

Example 12. Let A = Xx.xx, D = \xlX 2 .XlX 2 ^ and Pi = AA. We have: 
r{Q) = T{DAA) = T{XxiX2.xiX2X2)DA) = 

= T{XxiX2X^.x\X2Xz)D AA) = T{XxiX2Xz.x\X2X^xz)DDA) = 

= T{XxiX2X^xa.xiX2X^xa)DD AA) = • • • 

Since the set of legal paths of fi is not finite, T(I7) never terminates. 

5 Final Remarks 

Using linearization in practice. This work is carried out in the context 
of a larger project to explore the implications of linearization for programming 
language implementation. A number of practical concerns need to be addressed 
to make the technology presented in this paper usable in the overall project. In 
particular, the following tasks are important: 

1. Restrict the domain of application of our transformation to typable terms. 
This will decrease the lookahead needed to find out virtual redexes, and thus 
the complexity of the problem. 

2. Add support for built-in constructors such as booleans, conditionals, arith- 
metic and recursive definitions (a fixpoint operator or letrec bindings). One 
way to go is considering an initial linearization environment for built-ins. 

Theoretical concerns. In this paper we present a transformation of general 
terms into weak linear terms. In the presence of nontermination of reductions 
starting at the initial term, our transformation may not terminate (see example 
12). It is necessary to find out sufficient conditions for the initial terms, under 
which we can guarantee that the transformation terminates. For every example 
tested non-termination of the transformation coincides with the existence of a 
non-terminating path in the reduction graph of the term. This is somehow ex- 
pected since, apparently, the only cause of non-termination of the transformation 
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process is the existence of an infinite number of legal paths (which can only hap- 
pen when the term is not strongly normalizable). Based on this we conjecture 
that our transformation terminates if and only if the term is strongly normal- 
izable. The left-to-right implication is proved in Theorem 7. The right-to-left 
implication requires a more detailed analysis of the interaction between reduc- 
tions of the initial term and of the transformed term, and it is left for future 
work. 
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Abstract. Provably correct compilation is an important aspect in de- 
velopment of high assurance software systems. In this paper we further 
develop our approach to provably correct compilation based on Horn 
logical semantics of programming languages and partial evaluation. We 
show that the definite clause grammar (DCG) notation can be used for 
specifying both the syntax and semantics of imperative languages. We 
next show that continuation semantics can also be expressed in the Horn 
logical framework. Our approach has been applied for developing the se- 
mantics of the SCR specification language, the semantics is then used to 
(automatically) generate target code in a provably correct manner. 



In [2] we developed an approach for generating code in a provably correct manner 
based on partial evaluation and a type of semantics called Horn logical semantics. 
This approach is similar in spirit to semantics-based approaches, however, its 
basis is Horn-logical semantics [2] which possesses both an operational as well 
as a denotational (declarative) flavor. In the Horn logical semantics approach, 
both the syntax and semantics of a language is specified using Horn clause logic 
statements (or pure Prolog) . The semantics can be viewed dually as operational 
or denotational [7]. Taking an operational view, one immediately obtains an 
interpreter of the language C from the Horn-logical semantic description of the 
language L. Given a program V written in language £, the interpreter obtained 
for C can be used to execute the program. Moreover, given a partial evaluator for 
pure Prolog, such as Mixtus [6], the interpreter can be partially evaluated w.r.t. 
the program V to obtain compiled code for V [1,3]. Since the compiled code 
is obtained automatically via partial evaluation of the interpreter, it is faithful 
to the source of V, provided the partial evaluator is correct. The correctness 
of the partial evaluator, however, has to be proven only once. The correctness 
of the code generation process for any language can be certified, provided the 
compiled code is obtained via partial evaluation. Given that efficient execution 
engines have been developed for Horn Logic (pure Prolog), partial evaluation is 
relatively fast. Also, the declarative nature of the Horn logical semantics allows 
for language semantics to be rapidly obtained. 

* The authors have been partially supported by NSF grants CCR 9900320, CCR 
9820852, INT 9904063, by the Department of Education and the Environmental 
Protection Agency. 
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We have further developed the Horn logical semantics approach; we show 
that in Horn logical semantics not only the syntax but also the semantics can be 
expressed using the definite clause grammar notation. The semantics expressed 
in the DCG notation allows for the store argument to be naturally (syntacti- 
cally) hidden. As a result, code generated via partial evaluation does not have 
the store argument threading through. Moreover, we also show that continuation 
semantics can be expressed in Horn clause logic using the DCG notation. Con- 
tinuation semantics model the semantics of imperative constructs such as goto 
statements, exception handling mechanisms, abort, and catch/throw constructs 
more naturally. This continuation semantics views the program as a sequence 
of commands - a command is viewed as the difference between the current pro- 
gram and the command’s continuation. The semantic function maps a command 
represented as a difference to the the difference of two stores. We also show that 
continuation semantics expressed as DCGs can be partially evaluated w.r.t. a 
source program to obtain target code in a provably correct manner, even in the 
presence of imperative features such as the goto statements, abort commands, 
catch/throw, etc. 

The extensions have been applied to the SGR [4] (software cost reduction) 
method for specifying embedded real-time systems. Our approach based on par- 
tial evaluation is considerably faster than approaches based on generic program 
transformation systems [5]. 
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Abstract. Complete checks of database integrity constraints may be 
prohibitively time consuming, and several methods have been suggested 
for producing simplified checks for each update. The present approach 
introduces a set of transformation operators that apply to database in- 
tegrity constraints with each operator representing a concise, semantics- 
preserving operation. These operators are applied in a procedure produc- 
ing simplified constraints for parametric transaction patterns, which then 
can be instantiated and checked for consistency at run-time but before 
any transaction is executed. The operators provide a flexibility for other 
database enhancements and the work may also be seen as more system- 
atic and general when compared with other approaches. The framework 
is formulated with first-order clause logic but with the perspective of 
being applied with present-day database technology. 



1 Introduction 

Simplification of integrity constraints is a principle that has been recognized for 
more than two decades, dating back to at least [20], and elaborated by several 
other authors. Despite a general recognition, it has not gained ground in standard 
databases. Our work is an attempt to reconcile and generalize such ideas in a 
systematic way that may promote practical applications with current database 
management technology. 

An integrity constraint is a logical formula, typically depending on the na- 
ture of the application domain, that must hold for any database state for it to 
represent a meaningful set of data. Integrity constraints often concern the en- 
tire database and require linear or worse time complexity for a complete check, 
which is prohibitive in any non-trivial case. Simplification in this context means 
to derive specialized versions of the integrity constraints that can be checked 
more efficiently at each update, employing the hypothesis that the database is 
consistent before the update itself. Ideally, the simplified constraint should be 
a test that can be generated at database design time and that can be executed 
before a potentially offensive update is performed, so that rollback operations 
become unnecessary. 

This paper introduces a framework providing a set of semantics-preserving 
program transformations by means of which an effective simplification procedure 
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as well as other optimizations and database enhancements can be defined. In- 
tegrity constraints, here in the form of denial clauses, are considered as programs 
in the sense that they can be executed as Prolog queries that must fail or, more 
in the line with present-day database technologies, as SQL queries that must 
return the empty answer. Unlike some previous approaches, which only consider 
single updates, our simplification procedure (and the individual transformations) 
applies to transaction patterns. Once a specific transaction is proposed, and be- 
fore it is executed, the simplified formulas can be evaluated as pieces of code 
integrated in database application programs so that only consistency-preserving 
transactions are eventually given to the database. 

We also illustrate other applications of our framework combined with other 
techniques such as data mining, abductive reasoning and data integration. 

The paper is organized as follows. In section 2 we review existing literature in 
the field. The notation and theoretical setting are introduced in section 3, while 
in section 4 the program transformations and the simplification procedure are 
formally defined. Other applications are discussed in section 5 and concluding 
remarks are provided in section 6. 



2 Motivation and Related Works 

Simplification of integrity constraints, is highly relevant for optimizations in 
database integrity checking. Typically it gives a speed-up of a linear factor (in 
the size of the database state) for singleton updates but for certain transactions 
an even higher speed-up can be gained. We find crucial the ability to check 
consistency of a possibly updated database before execution of the transaction 
under consideration so that inconsistent states are completely avoided. Several 
approaches to simplification first require the transaction to be performed, and 
then the resulting state to be checked for consistency [20, 18, 23, 8, 11]. 

The proposal of [14] presents many analogies with our method, although the 
referenced paper does not present a fully developed method. A series of tests is 
generated from an integrity constraint C and an update U; if one of these tests 
succeeds, then U is legal with respect to C. This method is based on resolution 
and transition axioms, which provide an effect similar to our After operator (in- 
troduced in section 4 below). Updates are limited to be single actions, but can 
contain so-called dummy constants, very similar to our notion of parameters. 
The main disadvantage of this approach is that once the set of tests is gener- 
ated, strategies have to be employed to decide which specific tests to execute 
and in which order. Furthermore, failure of all tests does not necessarily imply 
inconsistency. Our simplification algorithm is more straightforward in that it 
generates a single test whose result is a necessary and sufficient condition for 
determining consistency of the database if the update were performed. 

Grant and Minker [11] introduce a principle called partial subsumption ap- 
plied among other things to produce simplified integrity constraints. This method 
applies to singleton additions or deletions and produces conditions to be applied 
after the update; it also handles parametric updates expressed using logical vari- 
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ables. For compound updates (transactions) the principle is explained in terms 
of examples, but no general procedure is described. Partial subsumption applies 
also to semantic query optimization; see [12, 10] for an overview. 

Qian [22] observes the relationship between Hoare’s logic [13, 9] for imperative 
languages and integrity checking, identifying a simplified integrity constraint as 
a weakest precondition for having a consistent updated state. This notion is 
enforced by assuming the consistency of the database before the update. We 
give a more detailed discussion of this issue in section 3. Qian’s method works 
for a variety of SQL-like ways of updating relations but with the impractical 
limitation that it does not allow more than one update action in a transaction 
to operate on the same relation; furthermore, no mechanism corresponding to 
parameters is present, thus requiring to execute the procedure for each update. 
We have no such restrictions. 

Another problematic issue inherent in most work in the field is the lack 
of a characterization of what it means for a formula to be simplified; this is 
traditionally defined in terms of a semantic criterion. Our view is that a trans- 
formed integrity constraint, in order to qualify as “simplified” , must represent a 
minimum in some ordering that reflects the effort of actually evaluating it. We 
propose a simple ordering based on the number of literals but we have no proof 
that our own algorithm hits a minimum in all cases. 

Standard ways of translating integrity constraints into SQL exist. In a re- 
cent paper [7], Decker shows how to implement integrity constraint checking 
by translating first-order logic specifications into SQL triggers. In this way the 
advantages of declarativity are combined with the efficiency of execution. It is 
interesting to note that the result of our transformations can be combined with 
similar translation techniques and thus integrated in a database system. An ex- 
tension of trigger syntax is proposed in [7] that allows the specification of the 
positions of the arguments of a relation that are relevant for an update. Our 
approach using parameters clearly subsumes this one. 

The use of constraint techniques for abduction in logic programming may 
display an incremental evaluation of integrity constraints without an explicit 
simplification algorithm: each time an abducible atomic update a arises, the cur- 
rent representation of the integrity constraints wakes up, checks a’s dependencies 
and, in case of success, delays a specialized version of the integrity constraints 
waiting for the next update. This principle is applied in the DemoII system [2, 5] 
and in the approach of [1] using Constraint Handling Rules for abduction; [3] is 
an attempt to relate such methods to database applications. However, a common 
drawback of these techniques is that the delayed constraints typically unroll to 
a size proportional to the database and that, occasionally, an unsatisfiable set 
of constraints is delayed where a failure should be reported. 

With few exceptions (e.g., [17, 16, 15,4]), little attention has been devoted to 
the problem of checking the integrity of a database containing recursive views, 
although recursion is now part of the current SQL standard. Consider, for exam- 
ple, a directed graph in which a path between two nodes is recursively expressed 
as the transitive closure of the edge relation and suppose that the graph is 
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acyclic. If a new edge a b is added, the optimal way to check whether the 
new graph still is acyclic is to verify that there is currently no path connecting 
b to a. None of the methods we are aware of is able to provide such a simplified 
check. When recursive rules are present, the methods described in [17,4] pro- 
duce a set of constraints which is typically the same as the original one, i.e., no 
actual simplification takes place during the application of the procedure. In [16], 
low-cost pre-tests are generated which are sufficient conditions that guarantee 
the integrity of the database; however, these pre-tests typically fail in the pres- 
ence of recursion, so nothing can be concluded about consistency. In [15], partial 
evaluation is applied to a general integrity checker to generate logic programs 
that correspond to simplified constraints. Generally, it is difficult to evaluate the 
method described in [15], as it depends on a number of heuristics in the partial 
evaluator as well as in the general checker; furthermore, no results are reported 
for recursive databases. The method we present here applies to non-recursive 
databases only. 

Technical difficulties related to undecidability may also hinder the realization 
of a perfect simplification method (see subsection 4.4). 

We are not aware of any other approach that reduces simplification into a 
combination of well-defined program transformations, which furthermore serve 
as an “algebra” in which different optimizations and interesting transformations 
can be described (see section 5). An experimental prototype [19] implementing a 
simplified version of these transformations is available on the World Wide Web. 

Finally, we emphasize that we only consider integrity constraints expressed 
relative to all states; constraints that compare successive states, by some authors 
called dynamic or transactional integrity constraints, are not considered. 



3 Preliminaries 

Assume a function-free first-order language equipped with negation and pred- 
icates for equality (=) and inequality (yf), called predefined predicates. Terms 
are either variables {x, y, ■ . ■) or constants (a, b, . . .). However, special constants 
called parameters are written in boldface (a, b, . . .); constants that are not pa- 
rameters are called ground constants. Predicates (p, q, ■ ■ ■) are used to build 
atoms, i.e. expressions of the form p{t\, . . . ,tn), where the Ws are terms and 
n > 0. A predicate that is not predefined is called a database predicate. Formu- 
las are formed as usual from the atoms and the logical connectives. A formula is 
ground if its terms are only ground constants. A literal is either an atom A or a 
negated atom -lA; whenever -i->A appears, it should be read as A and ~is = t a,s 
s ^ t and -IS yf t as s = t. Clauses are written in the form Head •<— Body where 
the head is an atom and the body a (perhaps empty) conjunction of literals; the 
head may be left out, understood as false, in which case the clause is a denial] the 
body may be left out, understood as true, in which case the clause is a fact] any 
other clause is a rule. (In) equalities are not allowed in the head and are assumed 
with their usual meaning of syntactic (in)equality, but the order in which the 
arguments of = and yf are written does not matter. Logical equivalence between 
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parameter-free formulas is denoted by =. The notation t indicates a sequence of 
terms ti, . . . ,tn and p{t) an atom whose arguments are ti, . . . , The expression 
t = s is a shorthand for = si A . . . A = s„ where ti’s and Sj’s are the terms of 
the two sequences; in a similar way, t ^ s refers to the disjunction of individual 
inequalities. 

Definition 1 (Parametric instance and equivalence). For any expression 
E with parameters a and sequence of constants c of the same length as a, the no- 
tation ifa/c refers to the expression that arises from E when each element of a is 
replaced consistently by the matching element of c; ifs/c is called a (parametric) 
instance of E. 

Two formulas F and G are equivalent up to instantiation of parameters, 
written F = G, whenever F' = G' for all parametric instances {F' , G') of {F, G). 

Clearly = is symmetric, reflexive and transitive. Note that name uniqueness is 
assumed for all ground constants but not for parameters, as different parameters 
may be instantiated by the same ground constant. 

Example 1. Let a, b be two parameters and c, d two ground constants. Then 
both p{c,d,c) and p(c, c, c) are instances of p(a,b,a), whereas p{c,c,d) is not. 
We have c = d = false but neither a = b = false nor a = b = true. Note that 
two formulas being parametrically equivalent does not necessarily indicate that 
they contain the same parameters, e.g. a = a = true. □ 

We further assume that all clauses are range restricted, as defined below. 

Definition 2 (Range restriction). A variable in a clause is range bound if 
it appears in a positive database literal in the body. A clause is range restricted 
if all variables in it are range bound. 

Notice that parameters in this definition are treated in the same way as ground 
constants. As already stated, we do not allow recursion, but our method is 
relevant for all database environments in which range restricted queries produce 
a finite set of ground tuples. The notion of subsumption is applied repeatedly in 
this paper. 

Definition 3 (Subsumption). A clause Ci subsumes another G^ iff there is 
a substitution a such that each literal in the body of Gicr occurs in the body of 
C 2 and similarly for the heads. 

Example 2. The clause ^ p{x, y) A a ^ x subsumes p{x, b) Ax ^ a A q{b). □ 

The definition of subsumption is syntactic but has the semantic property that 
the subsuming clause implies the subsumed one. 

Complying with [10], a database is characterized by three components: 

— a set of facts, called the extensional database] 

— a set of rules (the intensional database)] 

— a set of integrity constraints (here denials), known as the constraint theory. 
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Parameters cannot occur in a database but the transformation operators may 
produce integrity constraints that contain parameters. We call these parameter- 
ized integrity constraints. In a recursion-free language, we can limit our attention, 
without any loss of generality, to integrity constraints that refer to extensional 
predicates only, as intensional predicates can be (repeatedly) replaced with their 
definitions, that will eventually only be extensional. We will therefore keep this 
assumption throughout the rest of the paper. By database state we refer to the 
union of the extensional and the intensional parts only. 

As semantics of a database state D, with default negation for negative literals, 
we take its standard model, denoted as I? is here recursion-free and thus 
stratified. The truth value of a closed formula F, relative to D, is defined as 
its valuation in Md and denoted D{F). (See e.g. [21] for exact definitions.) 
The meaning of a formula that includes parameters can be thought of as an 
operator taking instantiations of the parameters and producing a truth value. 
In the following, the overloaded notation DfiFi) = £12(^2) will indicate that 
Di{F[) = D2{F!fi) holds for all parametric instances (£(,£3) of (£i,F2), where 
Di and D2 are database states and Fi and £2 are formulas. Consistency of the 
integrity constraints can be defined in different ways; we follow [10] arguing that 
the following is the most natural choice. 

Definition 4 (Consistency). A database state D is consistent with a con- 
straint theory F iff D{F) = true. 

Definition 5 (Update and update pattern). An update U = C/+ U U~ is 

a non-empty set 0/ additions C/+ and deletions U~ , both consisting of ground 
facts, with the deletions indicated by a sign. The reverse of an update U , 
denoted -^U, contains the same elements as U but with the roles of additions and 
deletions interchanged. The additions and deletions of an update are required to 
be disjoint, i.e. U'^C\-'U~ = 0. The notation D\JU , where D is a database state, 
is a shorthand for {D U U'^) \ ~dJ~ . An update pattern is an expression whose 
parametric instances are updates. 

This definition of update fits with all cases where the additions and deletions 
are known independently of the database state. This is not always the case. For 
example, given the statement “delete all records of computer science books from 
the library”, which is easily expressible in SQL, the set of tuples that will be 
deleted depends on the actual database state. Our method can be generalized 
to such more general updates including also SQL’s UPDATE, but for reasons of 
space this is omitted in the present version of the paper. 

As already emphasized, it is important to be able to test that a prospective 
database update does not violate the integrity constraints - without actually 
executing the update, i.e., a test is needed that can be checked in the present state 
but indicating properties of the prospective new state. A semantic correctness 
criterion for such a test is given by the notion of weakest precondition. 

Definition 6 (Weakest precondition, strongest postcondition). Let F 

and F' be constraint theories and U an update pattern. £' is a weakest pre- 
condition of F with respect to U and F is a strongest postcondition of £' with 
respect to U whenever D{F') = (£) U U){F) for any database state D. 
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As also noticed by Qian [22], this definition is similar to the standard axiom 
for defining assignment statements in a programming language [9], whose side 
effects are analogous to a database update. Hoare’s [13] original version of the 
axiom used only implication from pre- to postcondition; the notion of weakest 
precondition that we need is due to Dijkstra [9]. 

The concept of strongest postcondition is not used for simplification but is 
useful for other purposes. It characterizes how questions concerning the previous 
state may be answered by considering transformed questions in the updated 
state. The essence of simplification is the optimization of a weakest precondition 
based on the invariant that the constraint theory holds in the present state. The 
semantic characterization of this property is defined as follows. 

Definition 7 (Conditional weakest precondition). Let F be a constraint 
theory and U an update pattern. A constraint theory F' is a conditional weakest 
precondition of F with respect to U whenever D{F') = {D \J U){F) for any 
database state D consistent with F. 

A weakest precondition is also a conditional weakest precondition but not nec- 
essarily the other way round. All other known definitions of simplification are 
based solely on this or similar semantic notions, but this is not sufficient: a 
characterization should be given of the sense in which the resulting formula is 
actually “simpler” than the original one. In example 3 we show that a criterion 
based on semantic weakness does not capture the intuition behind simplicity. 

Example 3. In case a theory F\ holds in more states that another F 2 , we say that 
Fi is weaker than T 2 and that F 2 is stronger that A. Consider the constraint 
theory F = p{a)Aq{a), ^ r(a)} and the update U = {p(a)|. The strongest, 
intuitively simplest, and weakest conditional weakest preconditions of F with 
respect to U are shown in the following table. 



Strongest 


Simplest 


Weakest 




g(a)} 


q{a) A ~'p{a) A -r(a)} 



We shall use a syntactic selection criterion instead, as discussed in detail in 
section 4.2. 

4 Transformations on Integrity Constraints 

In the following, we define four syntactic transformation operators, each per- 
forming a well-defined function that satisfies straightforward semantic condi- 
tions. With these, we can compose a simplification procedure and, as shown in 
section 5, other useful transformations of integrity constraints. 

4.1 Translation of Integrity Constraints Back and Forth 
between Different States 

To consider whether a given property holds after a prospective update means to 
reason about the truth of a formula in a future state, but arguing in the present 
state. 
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The following After operator translates a constraint theory into a weakest 
precondition with respect to a given update pattern in a straightforward way; 
it does not assume consistency of the present state and is, thus, applicable for 
other things than plain simplification. By means of it, we define also a dual 
operator Before that translates a constraint theory F into another theory that 
can be used after the update to test whether F held before the update; it is not 
used in the simplification procedure, but it proves useful for other purposes, as 
shown in section 5. 

Definition 8. Consider an update pattern U: 

U = { pi(ayi),Pi(ai,2), • • ■ ,pi(ay„J, 

P2{d2,l),P2{d2,2), ■ ■ ■ ,P2{d2,n^), 

Pk{dk,l),Pk{Sk,2), ■ ■ ■ ,Pk{dk,Tik)y 

^P2{b2p),^P2{b2,2), ■■■, -^P2{b2,m2), 

~'Pk{bk,l),-<Pk{bk,2), • ■ • , ~'Pk{bk,mk)}^ 

where the pi ’s are distinct predicates and the dij ’s and bij ’s are sequences of 
constants. For a constraint theory F, the notation After*^(T) refers to the set of 
denials F' obtained as follows. 

F Let F' consist of a copy of F in which all occurrences of an atom of the form 
Pi{t) have been simultaneously replaced by 

A t yf A * * * A t yf bi^jnf) V f = Uip V * * * V f = ai^n^. 

2. Do the following in F' as long as possible (A, Bi, B 2 and C are formulas): 
— Replace any formula in F' of the form ^ A A (Bi V B 2 ) AC by the two 
formulas ^ A A Bi A C and ^ A A B 2 A C . 

— Replace any formula in F' of the form ^ A A -'{Bi V B 2 ) A C by the 
formula ^ A A -•Bi A -'B 2 A C . 

— Replace any formula in F' of the form ^ A A ~<{Bi A B 2 ) AC by the two 
formulas A. A -•Bi A C and ^ A A -'B 2 A C . 

The notation Before *^(T) refers to the set of denials After~'^(T). 

The intermediary formulas with disjunctions resulting from step 1 may not be 
clauses, but step 2 takes care of restoring the clausal form. The following prop- 
erties follow immediately from the definition of After and are stated without 
proof. 

Proposition 1 (Composition of After over denials). For any update U and 
constraint theories F\ and I 2 the following property holds: 

After'^(A U F 2 ) = After^(ri) U After^(T 2 )- 
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Proposition 2 (Composition of After over updates). For any constraint 
theory F and updates U , U\, U 2 , with U = C/i U C /2 and Ui and U 2 disjoint, we 
have 



After^(P) After^^(After^i(r)) After^i(After^"(r)). 

The semantic correctness of After is expressed by the following property. 

Theorem 1 (After produces weakest precondition). For any update U and 
constraint theory F, After^(T) is a weakest precondition of F with respect to U. 

Proof. We need to show that Zl(After^(T)) = (U U U){F) for any database 
state D. Step 2 of definition 8 obviously preserves semantics so we can ignore it. 
Composition over updates means that we need only consider singleton updates; 
we start considering a positive update of the form U = {p(a)|. 

For any database predicate q assume another predicate q' of the same arity, 
and when writing (p' for some formula or set of formulas <P (assumed not to 
include such primed predicates), we refer to a formula similar to <P with all oc- 
currences of database predicate q replaced by q' . Let II be the following program 
that defines a way of going back and forth between the two classes of predicates. 

{p' (x) ^ X = a \/ p{x)} U 

{q'{x) O q{x) I for any database predicate q different from p} 

The theory HU 77 is a combined representation of the states before and after the 
update, so that formulas without primes are evaluated as in the state before and 
primed ones as in the state after. Formally we have the following equivalences, 
where (p is any formula without primed predicates. 

{Dijnm 

{D U 77) (</>') - (77' U U')iP') - (77 U 7/)(0) 

To see that the last line holds, notice that the first two members are equivalent 
because they have the same definitions for all primed predicates: in the former 
p' holds when p holds or when its argument is a and in the latter p' is just a 
renaming of p plus the fact p'{a); all other primed predicates are evidently the 
same. The last two members are equivalent as they differ only by a consistent 
renaming of symbols. The two expressions (on the left-hand sides below) that we 
need to prove equivalent can be represented in the combined theory as follows: 

77(After'^(7")) ^ (77 U 77)(After^(r)) 

(77U7/)(r) ^ (77U77)(7"') 

However, the two right-hand sides are equivalent as After^(T^) can be constructed 
from F' by replacement of expressions that are equivalent in Dull, i.e., replacing 
p'{t) by (t = a V p{i)) and q'{i) by q{i) for any predicate q different from p. 

For a negative update of the form U = {-'p(a)} the proof is symmetric, with 
the definition of p' in 77 being {p'{x) O x yf a A p{x)}. □ 
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We get immediately composition properties of the Before operator and a dual 
version of theorem 1 stating that Before*^ produces strongest postconditions with 
respect to update U. 

Example 4- Consider a database containing information about marriages, where 
the binary predicate m indicates that a husband (first argument) is married 
to a wife (second argument). We expect for this database updates of the form: 
U = {m(a, b)}. The following integrity constraint is given: 

4> = <— m{x, y) A m(x, z) /\y ^ z 

meaning that no husband can be married to two different wives. The first step 
of definition 8 in the calculation of After^({(^}) generates the following: 

(m(x, y) V (a; = a A y = b)) A {m{x, z) V (a; = a A z = b)) A y yf z}. 

The second step translates it to clausal form: 

After^({(()}) = { ^ m(x, y) A m{x, z) f\y ^ z, 

m{x, y)Aa; = aAz = bAyyfz, 
a; = aAy = bA m{x, z) !\y ^ z^ 

-f— a: = a A y = b A a; = a A z = b A y yf z }. □ 

Example 5. We shall now consider an example of referential integrity, where a 
relation / (father) is only meaningful if its first argument (the father) is recorded 
in a relation p (person) with a specific constant value concerning the gender (m 
for “male”): 

0 ^ /(x, y) A ~^p{x, m) . 

For transactions of the form U = {/(a, b),p(a, m)} we have: 

After^({(()}) = {-^x = aAy = bA -^{x = a) A -•p{x,m), 

<— x = aAy = hA ~<{m = m) A ~'p{x, m), 

^ f{x,y) A -.(a; = a) A ~^p{x,m), 

f{x, y) A -i{m = m) A ~'p{x, m)}. □ 

Notice that when a predicate that appears in a positive literal is updated pos- 
itively by a single addition, After^({(()}) contains a copy of </> (see example 4), 
whereas for a predicate that appears in a negative literal, After^({(()}) contains 
a formula that is a specialization of 4>, even when the update is not singleton 
(see example 5). The effect is symmetric for deletions. 

4.2 Normalization of Formulas 

The result of the After transformation is obviously not in any “reduced” or 
“normalized” form, and we introduce an operator Norm to take care of this. 

An ideal Norm procedure should produce a constraint theory as output that 
is minimal in some ordering that reflects an estimate of the time complexity. This 
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can only be an estimate as the actual execution times depend on the database 
state (that is not available at the time of the simplification process) and is 
also highly dependent on the applied database technology that may perform 
optimizations that are not feasible to include in a general definition. We suggest 
an ordering based on the simple principle of counting literals, although it may 
be the case that longer constraints are evaluated more efficiently in particular 
database states (see also section 5.6). We define F ^ T' iff r' has fewer literals 
than r' . 

This may appear a bit coarse as it gives the same measure for, say, ^1 = 2, 
p{a), and •<— p{x). However, it should be kept in mind that the Norm procedure 
(as well as the entire simplification process) should return a minimal constraint 
theory among those that satisfy the corresponding semantic condition. 

We give a proposal below for a procedure that implements the Norm operation 
but we do not have a proof that it produces a minimal constraint theory^ . We 
are not alone with this problem, as no other work on simplification that we are 
aware of provides results of this form; in fact, we are not aware of any other 
work that considers this criterion at all. 

In the following definition we also refer to the notion of expansion [10]: the 
expansion of a clause consists in replacing every constant in a database predicate 
(or variable already appearing elsewhere in database predicates) by a new vari- 
able and adding the equality between the new variable and the replaced item. 
For example, ^ p{x, a, x) can be expanded to p{x, y,z)/\y = a/\z = x. 

Definition 9 (Normalization). For a constraint theory F, let Norm(F) he the 
result of iterating the following steps on F as long as possible, where x is a 
variable, t is a term, and A, B are (possibly empty) conjunctions of literals. 

Variable elimination: If a clause (f G F contains an equation x = t, 
remove it and replace all occurrences of x in 4> by t. 

Redundant constraints: Remove any denial that is subsumed by another 
denial in the current set. 

Redundancy within constraints: In any denial that can he written G- 
A /\ B so that A logically implies B, remove B (can he done by a straight- 
forward procedure searching for specific patterns such as trivially satisfied 
(in) equalities). 

Contradiction removal: Remove any denial B where B is unsatisfiable 
(can he done by a straightforward procedure searching for specific patterns). 
Folding by resolution (FbR): If there are two denials that, after expan- 
sion, have the form ^ A A L and {g- A A ~<L A B)a where L is a literal 
and a a substitution, the second denial is replaced by (g- A A B)a. 

^ It is clearly possible to enumerate in finite time all constraint theories preceding 
the original one in the selected ordering, as the set of symbols is finite. However, 
the problem of determining whether a constraint theory satisfies a given semantic 
condition (in this case, being a conditional weakest precondition) is likely to be 
undecidable. See subsection 4.4 for further discussion. 

^ According to notational convention, the actual negation may appear in either of the 
two clauses mentioned in FbR. 
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Notice that if the empty clause is produced during the process, then Norm(_r) = 
false, as it subsumes every other denial. 

The FbR step takes care of a sort of dependency “across” different integrity 
constraints that is a bit more subtle than the identification of redundant con- 
straints. These cases are not handled in the other approaches to simplification 
that we have studied, and we can expect that other specific optimizations of 
the same sort may be recognized in the effort to prove a minimality property. 
However, there are cases where an unfortunate order of the steps in the nonde- 
terministic Norm procedure makes it fail to remove certain redundant literals, 
but a refined version not presented here appears to avoid this problem. 

Proposition 3 (Semantic correctness of Norm). The Norm procedure ter- 
minates on any input, and for any constraint theory T, T = Norm(T). 

Proof. Termination follows from the fact that each step in the procedure reduces 
the constraint theory with respect to the ^ ordering which is obviously well- 
founded, apart from FbR that may generate an expansion which is anyhow 
removed by variable elimination. Lemma 1 below shows that FbR preserves the 
logical meaning. For all the other steps in Norm this property is evident. □ 

Lemma 1 (Validity of FbR). Let P he a constraint theory and P' he another 
constraint theory obtained hy applying FhR on P once. Then P = P' . 

Proof. We need only consider the logical equivalence between the two constraints 
mentioned in definition 9 before and after the replacement in the FbR step 
(the expansion step clearly preserves equivalence); assume the notation in that 
definition so that <j) below represents the before-constraints and 'ip the after- 
constraints, a a substitution. 

(j) = — A f\ L, ("^ — H A —'L A R)fj). 

The first denial is equivalent to H — >■ ~^L, from which we conclude that A A -iL 
and A are equivalent. Therefore (p = A A L, (^ A A B)a} = ip. □ 

As a step towards a correct simplification procedure, we notice that the next 
proposition follows immediately from the previous results. 

Proposition 4. For any constraint theory P and update U , Norm(After^(T)) 
is a weakest precondition of P with respect to U. 

4.3 Subsumption Checks 

An essential step in the achievement of simpler integrity constraints is to employ 
the fact that they hold in the current database state, and remove those parts 
of the condition about the possible updated state that are implied by this. For 
this purpose, we define a transformation RSub that is used to remove those 
derived integrity constraints produced by other transformations, that are anyhow 
subsumed by the original ones. 
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Definition 10 (Remove subsumed). Given two constraint theories F and 
r' , RSub^(/^') refers to a copy of F' in which 

— first, any denial subsumed by a denial in F is removed and 

— then, any remaining denial expandable to the form A A ~<L A B)a, for 
which a denial expandable to the form ^ A A L is in F, is replaced by 

A A B)a. 

We have immediately the following. 

Proposition 5. Let F' be a weakest precondition of F with respect to an up- 
date pattern U . Then RSub^(P') is a conditional weakest precondition of F with 
respect to U . 

4.4 Putting together a Simplification Procedure 

The transformation operators described in the previous sections comprise tools 
that can be used to define a procedure for simplification of integrity constraints, 
where the updates always take place from a consistent state. 

Definition 11. For a constraint theory F and an update U , we define 

Simp^(T) = RSub^(Norm(After^(T))). 

From the previous results we get immediately the following. 

Proposition 6. Let F be a constraint theory and U an update. Then Simp^(T) 
is a conditional weakest precondition of F with respect to U . 

Example 6. Consider again the update and the constraint theory from exam- 
ple 4, where we showed the transformation After*^ ({</>}). In order to obtain 
Simp^({(/)}), we first calculate Norm(After^({(/)})) as follows. The “variable elim- 
ination” step of definition 9 applied to After^ ({(/)}) generates the following set. 

{ ^ m{x, y) A m{x, z) Ay ^ z, 

^ m{a,y) Ay^h, 

^ m{a, z) Ah ^ z, 

^a = aAbyfb }. 

Then, “contradiction removal” eliminates the fourth constraint and, finally, the 
“redundant constraints” step removes the third constraint, as it is subsumed 
by the second one^. The output of the normalization procedure is therefore the 
following. 

Norm(After^({(/)})) = { ^ m{x, y) A m{x, z) Ay ^ z, 

^ m(a, y) A y yf b }. 

The first constraint is obviously subsumed by (j) and thus removed by RSub in 
the simplification procedure. 

Simp'^ ({(?;.}) = m(a, y) A y yf b}. □ 

® Alternatively, the second constraint could be removed instead of the third one, as 
they subsume one another. 
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Example 7. Reconsider now the update and the constraint theory from example 
5. We have here: 

Simp*^({(/)}) = 0. □ 

A detailed trace for the evaluation of these simplified formulas will show that 
RSub removes (j) from the resulting set of formulas when a predicate with only 
positive occurrences is updated, and a nontrivial specialization of 4> when a 
predicate with a negative occurrence is updated. 

The following example shows different combinations of singleton and com- 
pound updates for predicates occurring in positive and negative literals. 

Example 8. The following transformations hold for the integrity constraint tj) = 
p{x) A q{x) A -<r{x) and parameters a and b. 



({(/)}) 


= {^ 


q{a) A 


-.r(a)} 


Simp^«(‘’)>({0}) 


= {^ 


p(b) A 


^r(b)} 


Simp{"(")>({0}) 


= 0 






Simp{p(«)'"(b)}({^}) 


= {^ 


g(a) A 


-T(a) A 




= 0 






Simp{p(«)>«(‘>)}({<^}) 


= { ^ <?(a) t' 


' -r(a), 



^ p(b) A -'r(b), 

^ a = b A -ir(a) } □ 

As shown in examples 6, 7 and 8, the simplified integrity constraints are minimal 
in the ^ ordering and instantiated as much as possible. 

In case the original constraint theory contains redundant constraints (i.e., 
entailed by other constraints in the set), it is possible to construct examples 
where the result produced by our procedure would also contain redundancies. 
Cyclic patterns and recursive definitions can, for instance, be encoded in the in- 
tegrity constraints, thus rendering the detection of redundancy computationally 
harder. We have not investigated this phenomenon in depth, but it seems to 
be undecidable in general whether a given constraint is redundant, as it would 
amount to the query containment problem in datalog, which is known to be 
undecidable. This means that we can only hope to prove the optimality of our 
procedure under certain restrictions to the original constraint theory, e.g., that 
no recursion is encoded. 

The following proposition demonstrates the idea that integrity constrains can 
be “pre-compiled” at design time and then used against specific updates. 

Proposition 7. Let U{a) be a generic update request with sequence a of param- 
eters, c any matching sequence of ground constants, and E a constraint theory. 
Then 

The left-hand side can be thought of as a simplification made at update time, 
whereas the right-hand side uses a pre-compiled version produced at design time 
in which the parameters are replaced by the actual ground constants when the 
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update arrives. Note that the former may be simpler (according to -<) than the 
latter. Apart from [14,11], most works on simplification have not made such a 
distinction so that the procedures apply to specific updates only and, thus, need 
to be employed over and over when the database is running. 

5 Other Applications and Examples 

We briefly mention here several applications of our transformation operators 
that go beyond the scope of simplification. 



5.1 Generating Consistent Updates by Abductive Reasoning 

It may be the case that a proposed update, which in itself will create inconsis- 
tency in a given database state, can be extended to an update that preserves 
consistency. In a database application program, this situation may be handled 
by entering a dialogue in order to get more information. 

Consider as an example the referential integrity constraint of example 5, 

f{x, y) A -<p{x, m), and how an application program should handle an update 
request described by the update pattern /(a, b); the simplified version of the 
integrity constraint becomes •<— ->p{a.,m). 

At runtime, with a specific database state and instance of the parameters, the 
evaluation of this simplified integrity constraint may signal an inconsistency. In 
that case, the failing constraint gives a proposal for how the consistency may be 
repaired, namely by an update described by the pattern p(a, m) . This principle is 
closely related to abduction in logic programming, where literals that otherwise 
would fail are assumed in order to get a query to succeed. 

This extended update should not be suggested to the user in case it con- 
flicts with other integrity constraints. Thus simplified integrity constraints for 
{/(a, b),p(a,m)} need to be checked. 

The interesting point is that the different simplifications can be constructed 
beforehand and added once and for all and embedded as code in the user in- 
terface program. In general, this may be structured in a decision tree with each 
edge labelled by an extension to the update pattern plus a simplified integrity 
constraints. The tree splits into different branches when there are more than 
one remaining literal in a failing constraint, i.e., several different ways to achieve 
consistency may be possible. Either the database designer has made a choice or 
the user is asked which way to go. 

In the example, the insertion of p(a, m) may conflict with another integrity 
constraint saying that a person can only have one gender; in this case the dialogue 
with the user enters a new level. 



5.2 Preventing Duplicates 

We re-examine here the scenario considered in examples 4 and 6 and include a 
check to avoid duplicates, i.e., an attempt to add a tuple which is already in the 
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database is rejected. By a simple manipulation of the transformation operators, 
we can define a new simplification operator that includes this. 

Definition 12. For a constraint theory F and an update U , we define 

Simp^^(r) = RSub^(Norm(^ [/UAfter^(r))) 

where U is a shorthand for ui, . . . u„}, the elements of U being the 

variable-free literals tti , . . . , tt„ . 

The “nd” subscript stands for “no duplicates”, which is characterized here by 
the fact that any redundancies between the update and the weakest precondition 
expressed by After should be eliminated by Norm. It is easy to check that with 
U and (j) from example 4 we have 

= {^ m(a,i/)} ^ m(a, y) A y yf b} == Simp^({(/)}). 

In the calculation of Simp^^({(?;'}), FbR applies to the denials ^ m(a, b) and 
m(a, y) A y b (expanded, respectively, to ^ m{x, y)Ax = aAy = b and 
m{x,y) Ax = a Ay yf b), generating ^ m{x,y) Ax = a. This example showed 
how a new assumption could be embedded in the simplification procedure to 
generate a constraint theory which is clearly minimal in terms of the ordering 

5.3 Maintaining Integrity Constraints in Data Mining Applications 

Data mining techniques exist that are used to unveil integrity constraints in- 
herent in a database. These integrity constraints may then be used for various 
purposes, such as semantic query optimization and integrity checking. Suppose 
that an update comes up that violates the induced integrity. The data miner 
might either give up the constraint that has been violated, in that it does not 
model the underlying database anymore, or extend the integrity constraint to 
use the offending update as a counter-example. For example, let the following 
be a mined integrity constraint: 

(f> = <— p{x) A q{x) 

and assume that update U = {p(a)} violates it. Instead of rejecting (f, a perhaps 
clever approach is to regard U as an exceptional behavior of </> and produce a 
modified version, for example: 

(j)^ = A- p{x) A X yf a A q{x) 

The transformation from <f> to <fP is exactly what the Before transformation is 
doing, as in general D{(j>) = (D U C/ )( Before ^((^)) for any database state D. 

Some heuristics or application domain information can also be applied here 
to determine an upper limit to the number of exceptions allowed, above which 
the system eventually decides to reject (j). 

Another system might go into a dialogue with the user by questioning whether 
the mined is a property of the domain and should be trusted; if yes, the system 
may continue as described in section 5.1. 
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5.4 Checking the Integrity after the Update 

Although we generally have argued against it, there may be specific applica- 
tions where database updates should be executed immediately and consistency 
checked directly on the updated database. Our Before operator can be used in 
such a case in order to convert our precondition style simplifications into a form 
that tests the updated state: 

Proposition 8. Let a database D he consistent with a constraint theory F. Then 
the database state D U U is consistent with F iff D UU is consistent with the 
following: 



Norm ( Before^ (Simp^(P))). 

Example 9. Consider integrity constraint 6 p(x) A q(x) A -r(a;) and update 
U = {p{a),q{h)}. We have: 

Simp^d^}) = { ^ a = b A -•r(a), 
p(b) A -r(b), 

^ q(a) A -ir(a) }. 

Assuming that F was applied to a consistent database state, the updated state 
is consistent iff the following holds in it: 

{ ^ a = b A -T(a), 

^ p(b) A -'r(b), 

^ q(a) A -nr(a) }. □ 

As it can be seen in this example, the test produced in this way for the updated 
state is identical to the original, simplified one for the state prior to the update. 
Whether this indicates a general property is not known at the time of writing. 



5.5 Applications for Data Integration 

Data integration is the problem of combining two or more existing source data- 
bases into a single global one by means of a so-called mediator schema. The global 
database may be inconsistent even if each of the sources satisfies its particular 
constraints. In [6] we have adapted the simplification method described in the 
present paper to a number of different data integration scenarios, where the 
consistency of the sources is employed, perhaps together with given a priori 
knowledge on their combination. 

Example 10 ([6]). Consider two databases containing information about mar- 
riages, each of which is known to satisfy the following integrity constraint (no 
husband has more than a wife): 



(p = <— m{x, y) A m{x, z) !\y z. 
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A simplified constraint for checking consistency of the combined database 
(formed by the union of the tuples) produced by the method is the following, 
where the subscripts refer to the different local databases. 

4 > i ,2 = mi(x, y) hmiix.z) hy ^ z 

The simplification procedure can also be applied to validate, at the global level, 
an update reported from one of the local databases, based on the knowledge 
that the global database was consistent before the update and that the update 
was checked by the source. If, for example, the update {mi{frederik, mary)} is 
reported, the simplified check for global consistency is the following: 

2 ^ m2{frederik, z) A mary ^ z. 

If, in addition, it is known that the sets of husbands in the two sources are always 
disjoint, as expressed by the constraint ^ mi{x, y)/\m2{x, z), both (/>( 2 and 4>i^2 
could be further simplified by our method to true. □ 

5.6 Semantic Query Optimization 

We indicate here a potentiality for using the simplification procedure for semantic 
query optimization by a sketchy example. 

Consider again the integrity constraint ^ f{x,y) A ~'p{x,m) and assume 
that a given database is consistent with it. The query ^ f{x,y) is given to the 
system. Treat the variables in the query as parameters, thus writing it as /(a, b), 
and simplify the integrity constraint with respect to it. This gives for sure that 
^ -'p(a, m) holds for any a with /(a, b) in the database. 

This means that we can safely extend the query to the following: •<— p{x, m) A 
f{x, y). It may be the case that the new literal refers to a very small relation so 
that the remaining query runs faster (although this is not likely to be the case 
in the present example, however). 

6 Conclusion 

We applied program transformation techniques to the generation of simplified 
integrity constraints. A procedure was constructed that makes use of these trans- 
formations and produces the simplification searched for according to a criterion 
of “minimality” that is relevant for a large class of cases. This minimality and the 
versatility of the transformation operators are the original contribution of this 
paper. This, together with the ability of producing a necessary and sufficient 
condition for checking the integrity before a database transaction, constitutes 
the main advantage of our method with respect to earlier approaches. Examples 
are discussed that show how this procedure can be applied and it is also pointed 
out that the program transformations prove useful in several other contexts. 

Although the details were not spelled out, the simplified integrity constraints 
are assumed to be executable as SQL queries. In this context, an empty answer 
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indicates that the database is consistent, otherwise the tuples returned provide 
hints for extending the update in order to restore consistency, c.f. section 5.1. 

Future directions include the extension of the transaction language to cover 
the expressive power of today’s querying languages, which can be handled by 
extending the After operator with suitable replacement patterns. Extension of the 
simplification method to databases with recursive views is under consideration. 

As we have indicated, there seem to be undecidability results that make 
it impossible to achieve a general and optimal simplification procedure, so the 
modest goal we can hope for is to provide a procedure that is proven to produce 
optimal results under given restrictions to the constraint theory, and acceptable 
results in all other cases. 
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Abstract. One lesson learned from practical constraint solving applica- 
tions is that constraints are often heterogeneous. Solving such constraints 
requires a collaboration of constraint solvers. In this paper, we introduce 
a methodology for the tight integration of CHR constraint programs into 
one such program. CHR is a high-level rule-based language for writing 
constraint solvers and reasoning systems. A constraint solver is well- 
behaved if it is terminating and confluent. When merging constraint 
solvers, this property may be lost. Based on previous results on CHR 
program analysis and transformation we show how to utilize completion 
to regain well-behavedness. We identify a class of solvers whose union 
is always confluent and we show that for preserving termination such a 
class is hard to find. The merged and completed constraint solvers may 
contain redundant rules. Utilizing the notion of operational equivalence, 
which is decidable for well-behaved CHR programs, we present a method 
to detect redundant rules in a CHR program. 



1 Introduction 

Many real applications of constraint-based reasoning involve heterogeneous con- 
straints. Solving such constraints requires a collaboration of two or more con- 
straint solvers. In this paper, we are concerned with solvers written in CHR 
language. 

CHR (Constraint Handling Rules) [9,11] is a concurrent committed-choice 
constraint logic programming language consisting of guarded rules that manip- 
ulate conjunctions of constraints. In CHR, we distinguish two kinds of rules: 
simplification rules replace constraints by simpler constraints. Propagation rules 
add new constraints which may cause further simplification. 

Usually, CHR solvers are well-behaved, i.e. terminating and confluent. Conflu- 
ence means that it does not matter for the result which of the applicable rules are 
applied in a computation. Once termination has been established [10], there is a 
decidable, sufficient and necessary test for confluence [1]. Confluence also implies 
eonsisteney of the logical reading of the solver program [1]. We have developed 
a tool for confluence testing. All solvers of recent CHR releases are terminating 
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and only two solvers that rely on variable orderings to achieve termination for 
variable elimination are not confluent. 

Given two well-behaved CHR constraint solvers, then their so-called tight 
integration is simply the union of their rules. There is no restriction on the 
signature of the solvers. In particular, solvers may fully or partially define the 
same constraints. Any computation that was possible in one of the solvers will 
also be possible in the union of the solvers, since additional rules cannot inhibit 
the application of old rules (as can be seen from the operational semantics of 
CHR). 

However, the union of the solvers could lose termination and/or confluence, 
and thus their well-behavedness. 

Example 1. Consider a solver program with the single simplification rule {a 

b} that replaces the CHR constraint a by the constraint b and a solver 
program with the single rule {b a} that replaces the CHR constraint b by the 
constraint a. The union of the two programs, {a b, b a}, is obviously 
non-terminating . 

Consider a program P\ with the single rule {a b} and a program P 2 with 
the single rule {a c}. Their union {a<t^b, a c}is terminating, but 
obviously non-confluent, since a computation for a may result in either b or c 
depending on the (committed) choice of the rule. 

While establishing termination for CHR programs without propagation rules is 
in practice often rather simple [10], termination is in general undecidable for 
CHR programs. On the other hand, completion can make non-confluent pro- 
grams confluent [2] by adding new rules. Thus there is a chance to automatically 
produce from two well-behaved constraint solvers a solver that behaves well, too. 

Example 2. Consider the union of P\ and P 2 of Example 1, which is {a b, 
a c}. To make the union confluent, the rule b c can be added. 

In the paper, we also consider the special case of so-called non-overlapping solvers 
that define different constraints. Non-overlapping solvers may have common 
(shared) CHR constraints and function symbols and have common built-in con- 
straints. We prove that they are well-behaved if their union is terminating. While 
confluence is modular (preserved) for well-behaved, non-overlapping solvers, we 
will argue that it is very hard to And a syntactic class of solver programs that 
admits modularity for termination. 

In practice, non-overlapping solvers are integrated using so-called bridge 
rules between the different constraints they define. These bridge rules often de- 
stroy well-behavedness and we show by example how completion fares with such 
solvers. 

The resulting constraint solver may contain redundant rules. Since propa- 
gation in a rule-based constraint solver corresponds to a fixpoint computation 
with its rules, it is preferable to have a minimal number of rules to accelerate 
the fixpoint computation. Based on the operational equivalence notion [3], we 
present a method to detect and remove redundant rules in a CHR constraint 
solver. 
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Related Work. There is a renewed interest in languages and models for con- 
straint solver cooperation. An overview of the issues in cooperative constraint 
solving can be found in [14]. Recent work in this area includes BALI [16], a 
scheme for integrating heterogeneous solvers by encapsulation: a cooperation 
language based on strategies is compiled into solver specific communication code. 
Similarly, the framework of [8] relies on strategies to specify when component 
solvers are to be applied. The framework of [15] requires specific interfaces from 
the constraint solvers and a meta constraint solver to coordinate the cooper- 
ating solvers. Examples and implementations of this framework concentrate on 
numerical constraints. 

When CHR is used as an implementation language for constraint solvers, 
desirable properties like confluence and operational equivalence can be decided 
once termination has been established. There is no need for specific interfaces, 
because the constraint solvers communicate freely via shared variables using their 
common built-in constraints. In well-behaved CHR solvers, it does not matter 
which of the applicable rules are applied. In particular, in well-behaved merged 
solvers, it does not matter from which solvers the rules are coming. Thus any 
type of cooperation strategies [14], be it hard-coded, be it based on priorities or 
explicit operators, is possible. Moreover, the strategies can be very fine-grained, 
at the level of the application of a single rule from the solver program, i.e. single 
computation step. 

The work of [18, 7] focuses on building a constraint solver for the union 
of theories with given decision procedures. These theories are usually casted 
as equational theories. In [7], the theories are assumed to be disjoint. In [18], 
combination of theories sharing constructors have been investigated. In CHR, 
equalities referring to distinct theories are assumed to be represented by different 
constraint symbols. CHR programs represent first-order theories, that can be 
unioned without any requirements. Operationally, however, we want to make 
sure that the resulting solver is still well-behaved. The constraint solvers we 
are interested in are not necessarily decision procedures, but trade efficiency for 
completeness. 

In the term rewriting literature, there is a considerable body of work on 
modularity of termination and also work on modularity of confluence [17, 13, 
6] . Although CHR borrows notions and techniques from term rewriting systems 
(TRS), it is not clear how these results would apply to CHR, since CHR are 
rather different to classical TRS: 

— CHR propagation rules cannot be directly expressed as terminating TRS. 

— CHR manipulate constraints, which usually contain free variables, while 
terms that are rewritten in TRS are usually ground (variable-free). 

— Rule application in CHR relies on AC-matching of conjunctions of atomic 
CHR constraints (relations), and not on matching of terms at arbitrary po- 
sitions as in TRS. 

— Built-in constraints do not appear in TRS. CHR guards use built-in con- 
straints only and differ from conditions in extended TRS that refer to com- 
parison of normal forms of TRS reductions. 
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— Multiple occurences of variables are allowed on both sides of CHR rules. 
Variables are allowed to occur only in one side of the rule, in particular 
variables can be introduced on the right hand side of a rule. 

To the best of our knowledge, there does not exist a TRS with all these properties 
for which modularity results have been obtained. Clearly this does not preclude 
non-trivial future work to relate aspects of modularity in CHR with aspects of 
modularity results in TRS. 

Outline of Paper. In Section 2, we define the CHR language and summarize 
previous results on confluence, completion, and operational equivalence. In the 
next section of the paper, we show how to merge CHR constraint solvers utilizing 
completion. We then investigate when termination and confluence are preserved 
under union of solver programs. We consider the special case of so-called non- 
overlapping solvers that define different constraints and introduce the notion 
of so-called bridge rules to integrate such solvers. In Section 6, we show how 
to remove redundant rules from a solver utilizing operational equivalence. A 
preliminary version of this paper was presented at JFPLC’02 [4]. 

2 Preliminaries 

In this section we give an overview of syntax and semantics for constraint han- 
dling rules (CHR) as well as previous results on confluence, completion, and 
operational equivalence. Detailed presentations can be found in [12, 1, 5, 2, 3]. 

2.1 Syntax of CHR 

We use two disjoint sets of predicate symbols for two different kinds of con- 
straints: built-in constraint symbols and CHR constraint symbols (user-defined 
symbols). We call an atomic formula with a constraint symbol a constraint. Built- 
in constraints are handled by predefined constraint black-box solvers. We assume 
that these solvers are well-behaved. Built-in constraints include =, true, and 
false. The semantics of the built-in constraints is defined by a consistent first- 
order constraint theory CT. In particular, CT defines = as the syntactic equality 
over finite terms. 

CHR constraints are defined by a CHR program. 

Definition 1. A CHR program is a finite set of rules. There are two kinds of 
rules: A simplification rule is of the form Name @ H C \ B. A propagation 
rule is of the form Name @ H ^ C \ B, where Name is an optional, unique 
identifier of a rule, the head H is a, non-empty conjunction of CHR constraints, 
the guard C is a conjunction of built-in constraints, and the body B is a goal. A 
goal is a conjunction of built-in and CHR constraints. For convenience, a trivial 
guard “true” can be omitted together with “I”. 

A CHR symbol is defined in a CHR program if it occurs in the head of a rule 
in the program. 
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Example 3. We define a CHR constraint for a partial order relation <: 

rl 0 X<X true . 
r2 0 X<Y A Y<X X=Y. 

r3 0 X<Y A Y<Z =l> X<Z. 

r4 0 X<Y A X<Y X<Y. 

The CHR program implements reflexivity (rl), antisymmetry (r2), transi- 
tivity (r3) and redundancy (r4) in a straightforward way. The reflexivity rule 
rl states that X<X is logically true. The antisymmetry rule r2 means X<Y A 
Y<X is logically equivalent to X=Y. The transitivity rule r3 states that the con- 
junction of X<Y and Y<Z implies X<Z. The redundancy rule r4 states that X<Y 
A X<Y is logically equivalent to X<Y. 

2.2 Operational Semantics of CHR 

The operational semantics of CHR is given by a transition system. A state is 
simply a goal, i.e. a conjunction of built-in and CHR constraints. Let P be a CHR 
program. We define the transition relation i— >-p by introducing two computation 
steps (transitions), one for each kind of CHR rule (cf. Figure 1). In the figure, all 
meta-variables stand for conjunctions of constraints. The notation Gu denotes 
the built-in constraints of G. Since the two transitions are structurally very 



Simplify 

If {H C I B) is a fresh variant of a rule with variables x 

and CT 1= V {Gu 3x{H^H' A C)) 

then {H' A G) (G A B A C A H^H') 

Propagate 

If {H ^ G I B) is a fresh variant of a rule with variables x 

and GT |= V {Gu 3x{H^H' A G)) 

then {H' A G) (B" A G A B A G A H=H') 

Fig. 1. Computation Steps of Constraint Handling Rules 



similar, we first describe their common behavior and only at the end point out 
their differences. 

A fresh variant of a rule is applicable to a state H' AG if H' matches its head 
H and if its guard C is implied by the built-in constraints appearing in G. A fresh 
variant of a rule is obtained by renaming its variables to fresh variables, listed 
in the sequence x. Matching (one-sided unification) succeeds if H' is an instance 
of H, i.e. it is only allowed to instantiate (bind) variables of H but not variables 
of H' . Matching is logically expressed by equating H' and H but existentially 
quantifying all variables from the rule, x. This equation H'=H is shorthand for 
pairwise equating the arguments of the constraints in H' and H , provided their 
constraint symbols are equal. Note that conjuncts can be permuted. 
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If an applicable rule is applied, the equation H=H', its guard C and its body 
B are added to the resulting state. A rule application cannot be undone (CHR 
is a committed-choice language without backtracking). When a simplification 
rule is applied in the transition Simplify, the matching CHR constraints H' 
are removed from the state. The Propagate transition is like the Simplify 
transition, except that it keeps the constraints H' in the resulting state. Trivial 
non-termination caused by applying the same propagation rule again and again 
is avoided by applying it at most once to the same constraints [1]. 

A computation of a goal G in a program P is a sequence Sg, Si, .. . of states 
with Si 5'i+i beginning with the initial state So for G and ending in a 
final state or diverging. A final state is one where either no computation step is 
possible anymore or where the built-in constraints are inconsistent, i— >-p denotes 
the reflexive and transitive closure of i— >-p. When it is clear from the context, we 
will drop the reference to the program P. 

Example f. Recall the solver program for < of Example 3. Operationally the 
rule rl removes occurrences of constraints that match X<X. The antisymmetry 
rule r2 means that if we And X<Y as well as Y<X in the current store, we can 
replace them by the logically equivalent X=Y. The transitivity rule r3 propagates 
constraints. We add the logical consequence X<Z as a redundant constraint. The 
redundancy rule r4 absorbs multiple occurrences of the same constraint. 

A computation of the goal A<B A C<A A B<C proceeds as follows: 



A<B 


A 


C<A 


A B<C 


1 ^Propagate 


A<B 


A 


C<A 


A B<C A C<B 


1 , Simplify 


A<B 


A 


B<A 


AB=C 


1 , Simplify 


CQ 

II 

< 


A 


B=C 







2.3 Confluence 

The confluence property of a program guarantees that any computation for a 
goal results in the same Anal state no matter which of the applicable rules are 
applied. 

Definition 2. A CHR program is confluent if for all states S, Si,S2- If S >->■* S'! 
and S !->■* S2 then the pair of states (S'!, S'2) is joinable. 

A pair of states (S'!, S'2) is joinable if there exist states Ti and T2 such that 
Si I— >■* Ti and S2 >— >■* T2 where Ti and T2 are identical up to renaming of 
variables and logical equivalence of built-in constraints. 

To analyze confluence of a given CHR program we cannot check joinability start- 
ing from any given ancestor state S, because in general there are infinitely many 
such states. However for terminating programs, one can restrict the joinabil- 
ity test to a finite number of “minimal” states, the so-called critical states as 
explained below. 

A CHR program is called terminating, if there are no infinite computations. 
For many existing CHR programs simple well-founded orderings are sufficient 
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to prove termination [10]. In general, such orderings are not sufficient because 
of non-trivial interactions between simplification and propagation rules. In this 
paper we assume that the constraint solvers are terminating. 

Definition 3. Let R\ be a simplification rule and R 2 be a (not necessarily 
different) rule, whose variables have been renamed apart. Let Hi A Ai be the 
head and Ci be the guard of rule Ri {i = 1,2). Then a critical ancestor state of 
Ri and R 2 is 

{Hi A Ai A H 2 A {A\=A 2 ^ a Cl A C 2 ), 

provided Ai and A 2 are non-empty conjunctions and CT \= 3{{Ai=A2) A Ci A 
C 2 ). 

Let S' be a critical ancestor state of R\ and i? 2 - If S i-A- Si using rule R\ and 
S I— >■ S 2 using rule R 2 then the tuple (Si, S 2 ) is a critical pair of Ri and i? 2 . 

The following theorem from [1,5] gives a decidable, sufficient and necessary 
condition for confluence of a terminating CHR program: 

Theorem 1. A terminating CHR program is confluent iff all its critical pairs 
are joinable. 

Example 5. Recall the program for < of Example 3. Consider a critical ancestor 
state of r2 and r3 where Ai = A 2 = X<Y. This critical state is X<Y A Y<X A Y<Z 
and gives raise to the following critical pair 

(Si,S2) = (X=Y a X<Z, X<Y a Y<X a Y<Z a X<Z) 

which is joinable: Si is a final state, i.e. no further computation step is possible. 
A computation beginning with S 2 results in Si: 

X<Y A Y<X A Y<Z A X<Z 

X<Z A X<Z A X=Y ,_j.Simplify 

X<Z A X=Y 

2.4 Completion 

Completion is the process of adding rules to a non-confluent program until it 
becomes confluent. Rules are built from a non-joinable critical pair to allow a 
transition from one of the states into the other while maintaining termination. 
In contrast to other completion methods, in CHR we need in general more than 
one rule to make a critical pair joinable: a simplification rule and a propagation 
rule [2]. When these rules are added, new critical pairs may be produced, but 
also old non-joinable critical pairs may be removed, because the new rules make 
them joinable. Completion tries to continue introducing rules this way until the 
program becomes confluent. The essential part of a completion algorithm is the 
introduction of rules from critical pairs. 

Definition 4. Let be a termination order and let {Cudi A Cmi , Cud 2 A Cbi 2 ) 
be a critical pair, where the states are ordered such that Cudi is a non-empty 
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conjunction and Cudi ^ C'«d2- Then the orientation of the critical pair results 
in the rules: 

Cudl ^bil I Cbi2 

Cud2 Cbi2 I Cbil 

The second rule is needed if Cud2 is a non-empty conjunction and CT ^ Cbi2 
Cbil- 

Examples of completion will be shown in the next section of the paper. In these 
examples, unless otherwise noticed, a simple termination order will suffice, where 
Cl ^ C2 if Cl = (C2 A C), i.e. the conjunction Ci contains all conjuncts of C2 
and more (C is non-empty). 

In [2] it was shown that if the completion procedure stops successfully, then 
the resulting program is well-behaved. But completion cannot always be suc- 
cessful: completion is aborted if a critical pair cannot be transformed into rules. 
Completion may not terminate, because new rules produce new critical pairs. 



2.5 Operational Equivalence 

The following definition clarifies when two programs are operationally equivalent: 
if for each goal, all final states in one program are the same as the final states 
in the other program. 

Definition 5. Let Pi and P 2 be programs. A state S' is Pi, P 2 ~joinable, iff there 
are two computations S 1— Si and S S2, where Si and S2 are final states, 
and Si and S2 are identical up to renaming of variables and logical equivalence 
of built-in constraints. 

Definition 6. Let Pi and P2 be programs. Pi and P2 are operationally equiva- 
lent if all states are Pi , P2-joinable. 

In [3], we gave a decidable, sufficient and necessary syntactic condition for op- 
erational equivalence of well-behaved CHR programs: when testing operational 
equivalence, similar to our confluence test, we can restrict ourselves to a finite 
number of critical states that consist of the head and the guard of a rule. These 
critical states are run in both programs, and their outcome must be the same. 

Definition 7. Let P\ and P2 be programs. Then a critical state of P\ and P 2 
is defined as follows: 

H AC where {H © C I P) G Pi U P2 and 0 G { , => } 

Theorem 2. Two well-behaved programs Pi and P2 are operationally equiva- 
lent iff all critical states of Pi and P2 are Pi, P2-joinable. 

Examples for operational equivalence can be found in the subsequent sections. 
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3 Tight Integration of CHR Constraint Solvers 
with Completion 

In the introduction, Example 1 illustrated that the union of two well-behaved 
(i.e. terminating and confluent) programs is not necessarily well-behaved. Once 
termination of the union has been established, we can use our confluence test 
to check if the union of well-behaved programs is confluent again. We call such 
programs “compatible” . 

Definition 8. Let Pi and P2 be two well-behaved CHR programs and let the 
union of the two programs, PiD P2, be terminating. Pi and P2 are compatible if 
Pi U P2 is confluent. 

The critical pairs of Pi U P2 are the critical pairs of Pi unioned with the critical 
pairs of P2 unioned with critical pairs coming from one rule from Pi and one 
rule from P2- Since Pi and P2 are already confluent, for compatibility it suffices 
to check only those critical pairs coming from rules in different programs (cf. 
proof of upcoming Theorem 3). In other words, the confluence test can be made 
incremental in the addition of rules. 

If the compatibility test succeeds, we can just take the union of the rules 
in the two programs. This holds even for constraints that are fully or partially 
defined in more than one of the programs which are merged. 

Example 6. The well-behaved program Pi contains the following CHR rules 
defining max, where max(X,Y,Z) means that Z is the maximum of X and Y: 

max(X,Y,Z) X<Y I Z=Y. 

max(X,Y,Z) X>Y I Z==X. 

whereas well-behaved P2 defines max by 

max(X,Y,Z) X<Y I Z=Y. 

max(X,Y,Z) X>Y I Z=X. 

Note that <, <, and > are built-in constraints in this example. 

In order to perform the union of the two programs, we check whether the 
definitions of max are compatible. There are three critical ancestor states coming 
from one rule in Pi and one rule in P2'. 
max(X,Y,Z) A X<Y A X<Y 
max(X,Y,Z) A X>Y A X<Y 
max(X,Y,Z) A X>Y A X>Y 

Since the critical pairs of these critical ancestor states are joinable, the two 
definitions of max are compatible. Hence we can just take the union of the rules 
and define max by all four rules. 

Note that the constraint max is “operationally stronger” in Pi U P2 than in 
each program alone, in the sense that more computation steps are possible: in 
Pi U P2 (and Pi) we have the computation 

max(X,Y,Z) A X>Y H>PiuP2 Z=X A X>Y 




Integration and Optimization of Rule-Based Constraint Solvers 207 



while in P 2 the goal cannot reduce at all, it is a final state. But like P 2 , Pi is not 
as strong as Pi U P 2 : the goal max(X, Y,Z) A X<Y is a final state in Pi, while it 
has a non-trivial computation in Pi U P 2 and P 2 . 

Example 7. Here we consider a variation on a solver for max that does not use 
any built-in constraints (except for implicit syntactical equality) . We define max 
with the inequalities as CHR constraints in two steps. 

Given the constraint solver for < (example 3), we add the following simpli- 
fication rule describing the interaction of max and <: 

maxi 0 max(X,Y,Z) A X<Y Z=Y A X<Y. 

The resulting solver is non-confluent. The critical ancestor state max(X,X,Z) A 
X<X of the rule maxi and of the reflexivity rule rl of < produces the non-joinable 
critical pair (X^^Z A X<X, max(X,X,Z) ) . We use completion to make the solver 
confluent. For the above-mentioned critical pair it adds the rule: 

max2 0 max(X,X,Z) Z— X. 

Now, we consider a solver for < which is well-behaved 

X<X false . 

X<Y A X<Y X<Y. 

X<Y A Y<Z X<Z. 

and we add the rule describing the interaction of max and <: 

max3 @ max(X,Y,Z) A Y<X Z=X A Y<X. 

The resulting solver remains well-behaved. 

Finally, we union the solvers for < and for < that have been extended by the 
three rules for max, i.e. maxi, max2, and max3. The union of these solvers is not 
confluent. The completion method adds the following rule to make a non-joinable 
critical pair stemming from the rules maxi and max3 joinable: 

X<Y A Y<X false. 

The rules derived by completion revealed interesting properties of max, i.e. rules 
max2 and max3, and the interaction of < and <. The completed program is 
well-behaved. 

4 Modularity of Termination and Confluence 

We have seen that well-behavedness is not modular, i.e. it is not preserved under 
union of programs. We may ask ourselves if there are syntactic criteria for classes 
of programs that admit modularity of well-behavedness. In this section we will 
show that while for confluence, the answer is positive and simple (presupposing 
termination), the situation seems very difficult for termination. 

When the two solvers do not have any defined CHR constraints in common 
(i.e. a CHR symbol occurring in the head of the rules in a solver does not occur 
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in the head of the rules in the other solver), we call them non- overlapping. Note 
that non-overlapping solvers may have common (shared) CHR constraints and 
function symbols and have common built-in constraints (by definition, at least 
syntactical equality). We can show that the union of two non-overlapping well- 
behaved solvers is always well-behaved if the union is terminating. 

Theorem 3. Let Pi and P 2 be two well-behaved CHR programs and let the 
union of the two programs. Pi U P2, be terminating. If Pi and P2 are non- 
overlapping then Pi U P2 is confluent. 

Proof. To show that Pi U P2 is confluent, we only have to show that all critical 
pairs of Pi U P2 are joinable, since Pi U P2 is terminating. The set of critical 
pairs of Pi U P2 consists of all critical pairs stemming from two rules appearing 
in Pi (case 1. below), all critical pairs stemming from two rules appearing in P2 
(case 2) and all critical pairs stemming from one rule appearing in Pi and one 
rule appearing in P2 (case 3). 

1. Pi is well-behaved, thus all critical pairs stemming from two rules appearing 
in Pi are joinable. Therefore, these critical pairs are also joinable in Pi U P2. 

2. Analogous to case 1. 

3. Critical pairs from rules of different programs can only exist, if the head 

of the rules have at least one constraint in common. Since Pi and P2 are 
non-overlapping, there exists no critical pair stemming from one rule in Pi 
and one rule in P2. □ 

For modularity of termination, the situation seems very difficult: even if two 
terminating programs do not have common CHR constraint symbols, their union 
may be non-terminating. 

Example 8. Consider the following two programs: 

PI: c(f(X)) X=g(Y) A c(Y). 

P2: d(g(Y)) Y=f(Z) A d(Z) . 

Any goal (of finite size) terminates in each of the two programs, but the goal 
c(f (X) ) A d(X) does not terminate in the union of the programs (due to com- 
mon function symbols). 

c(f(X)) A d(X) ^Simplify 

X=g(Y) A c(Y) A d(g(Y)) ^Simplify 

X=g(f(W)) A Y=f(W) A c(f(W)) A d(W) . . . 

Actually, even if there are no common symbols in the program text, we may run 
into trouble. 

Example 9. The previous example can be rewritten such that instead of common 
function symbols one uses built-in constraints to the same effect: 



PI: c(FX) fl(FX,X) I gl(X,Y) A c(Y). 

P2: d(GY) g2(GY,Y) I f2(Y,Z) A d(Z) . 
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where fl{X,Y) and f2{X,Y) are both defined as X = f{Y) in the constraint 
theory for the built-in constraints and analogously for g\{X,Y) and g2{X,Y). 
There are no common symbols in the CHR program itself, but only in the con- 
straint theory. Any goal terminates in each of the two programs, but the goal 
c(FX) A fl(FX,X) A d(X) does not terminate in the union of the programs. 

Summarizing, as soon as there are common symbols, no matter if they are CHR 
constraints, built-in constraints or function symbols (even when only shared in 
the built-in constraint theories), termination is in danger. But any non-trivial 
integration of constraint solvers will at least share some function symbols, oth- 
erwise there could not be shared variables in goals, and without shared variables 
there is no non-trivial communication between the solvers. 

5 Cooperation Using Bridge Rules and Completion 

In practice, one will often add to the union of non-overlapping solvers a few so- 
called bridge rules. These are rules that may translate constraints from one solver 
to constraints of the other solver to improve the overall solving power, i.e. more 
propagation is possible. In general, they relate constraints from different solvers 
to enable non-trivial cooperation. In other words, they define communication 
between the solvers by sharing data (constraints). 

When adding bridge rules, care has to be taken to maintain termination. On 
the other hand, bridge rules can be used to re-introduce termination: we may 
make a union of solvers terminating by renaming symbols apart and using bridge 
rules to control the interaction between the solvers. In any case, terminating 
bridge rules will typically cause non-confluence and thus will be the starting 
point for completion. 

Example 1 0. We want to build a Boolean constraint solver from a well-behaved 
program Pi defining conjunction and a well-behaved program P 2 defining im- 
plication. In Pi, the constraint and(X,Y,Z) stands for X A Y o Z and in P 2 , 
imp(X,Y) stands for X — >■ Y. 

PI: and(X,X,Z) X=Z. 

and(X,Y,l) X=1 A Y=l. 

and(X,l,Z) X=Z. 

and(X,0,Z) Z=0. 

and(l,Y,Z) Y=Z. 

and(0,Y,Z) Z=0. 

and(X,Y,Z) A and(X,Y,Zl) and(X,Y,Z) A Z=Z1. 

P2: imp(0,X) true. 

imp(X,0) X==0. 

imp(l,X) X=l. 

imp(X,l) true. 

imp(X,Y) A imp(Y,X) X=Y. 
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We add the following bridge rule: 
and(X,Y,X) imp(X,Y). 

The program containing P\ and P 2 together with the bridge rule is not con- 
fluent: the critical pair {true, imp(X,X)) stemming from the critical ancestor 
state and(X,X,X) of the first rule of and and the bridge rule is not joinable. 
Completion generates the following rules from the non-joinable critical pairs: 

imp(X,X) true. 

imp(X,Y) A imp(X,Y) imp(X,Y). 

imp(X,Y) A and(X,Y,Z) imp(X,Y) A X=Z. 

Again, the automatically derived rules reveal interesting properties of the con- 
straints. 

6 Removal of Redundant Rules 
with Operational Equivalence 

Since propagation in a rule-based constraint solver corresponds to a flxpoint 
computation with its rules, it is preferable to have a minimal number of rules 
to accelerate the flxpoint computation and thus to improve the efficiency of 
the constraint solver. A smart flxpoint engine may detect redundant rules at 
run-time, but it is obviously cheaper to remove them at compile time or before. 

We can use a variation of the operational equivalence test [3] between pro- 
grams to remove redundant rules from the (completed) union of constraint 
solvers. 

Definition 9. A rule R is redundant in a CHR program P iff for all states S': 
If S I— >-p Si then S S 2 , where Si and S 2 are final states and Si and 

S 2 are identical up to renaming of variables and logical equivalence of built-in 
constraints. 

Example 11. In example 6, the union of the two programs defining max 

rl 0 max(X,Y,Z) X<Y I Z=Y. 

r2 0 max(X,Y,Z) X>Y I Z=X. 

r3 0 max(X,Y,Z) X<Y I Z=Y. 

r4 0 max(X,Y,Z) X>Y I Z=X. 

was operationally stronger than each program alone. However, the union contains 
redundant rules. For example, rule r3 can always make a transition when rule 
rl does, with the same result, but not vice versa. Hence rule rl is redundant, 
and analogously for rule r4. 

Redundant rules can be discovered using operational equivalence: We remove 
one rule from the program and compare it with the original program. If the two 
programs are operationally equivalent, then the rule was obviously redundant 
and we can remove it. We continue until we have tried to remove all rules. The 
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final program found this way is not necessarily unique, since the result may 
depend on the order in which rules are tried and removed. 

However, Theorem 2 may not be applicable for our redundancy check: If we 
remove a rule from a well-behaved program, it may become non-confluent. In 
order to come up with a decidable rule redundancy test, we first have to test 
confluence of the program without the candidate rule for redundancy. If the 
program is not confluent, it cannot be operationally equivalent to the initial 
program, and hence the candidate rule cannot be redundant. If the program is 
confluent, we can and must check for operational equivalence. 

Theorem 4. Let P be a well-behaved program. A rule R is redundant with 
respect to P iff P\{R} is well-behaved and all critical states of P and P\{R} 
are P, P\{P}-joinable. 

Proof. First, we prove the claim that P\{R} is well-behaved by contradic- 
tion. Assumption: P\{R} is not well-behaved. We can distinguish two cases: 

1 . P\{R} is non-terminating, thus P is also non-terminating, which is a 
contradiction to the fact that P is well-behaved. 

2 . P\{R} is non-confluent, thus there exists a state S such that S 

51 and then S S2, where Si and S2 are final states, and and 

52 are not identical up to renaming of variables and logical equivalence 
of built-in constraints. R is redundant with respect to P, therefore there 
exists a state S3 such that S i-^-p S3, where S3 is a final state, and S3 
and Si as well as S'3 and S2 are identical up to renaming of variables 
and logical equivalence of built-in constraints. This is a contradiction to 
the claim that Si and S2 are not identical up to renaming of variables 
and logical equivalence of built-in constraints. 

Now we prove that all critical states of P and P\{R} are P, P\{P}-joinable. 
R is redundant with respect to P, thus for all states S the following holds: 
S I— >-p Si then S 1— S2, where Si and S2 are final states and Si and S2 
are identical up to renaming of variables and logical equivalence of built-in 
constraints. Therefore, all states are P, P\{P}-joinable. □ 

It is easy to see that we can specialize our operational equivalence test for re- 
dundancy removal: We only have to check if the computation step due to the 
candidate rule that is tested for redundancy can be performed by the remainder 
of the program, but we do not have to consider any other rule prefixes. 

Example 12. The critical states of the program P in Example 11 are 

csl: max(X,Y,Z) A X<Y 
cs2: max(X,Y,Z) A X>Y 
cs3: max(X,Y,Z) A X<Y 
cs4: max(X,Y,Z) A X>Y 

Note that any subset of the program in Example 11 is still well-behaved. A 
program P\{R} (P G {rl, r2, r3, r4}) obviously cannot contribute any new 
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critical states. So if we try to remove rule rl we only have to check the critical 
state from rule rl, that is csl, by running it in both programs: 

max(X,Y,Z) A X<Y H>p X<Y A Z=Y by rule rl 

max(X,Y,Z) A X<Y X<Y A Z=Y by rule r3 

Since rule r3 enables the same transition, rule rl must be redundant. In an 
analogous way, redundancy of rule r4 can be shown. Rule r2, however, is not 
redundant: 

max(X,Y,Z) A X>Y H>p X>Y A Z=X by rule r2 

max(X,Y,Z) A X>Y ^/^p\{r 2 } 

In program P\{r2}, the critical state is a final state. Hence (the only) re- 
dundancy free program consists of the rules r2 and r3. 

7 Conclusions 

In this paper, we have shown that terminating and confluent, i.e. well-behaved 
CHR constraint solvers can be merged provided termination is preserved: their 
tight integration is the union of the rules, even if some constraints are fully or 
partially defined and/or used in several solvers or program parts. In case that 
the resulting solver becomes non-confluent, we use our completion method to 
improve its behavior. 

Non-overlapping solvers do not define common constraints but may freely 
share them otherwise. We have shown that their union is always well-behaved if 
it is terminating. We argued that a similar modularity result for termination is 
likely to be very hard to obtain. Future work will investigate how to maintain 
termination of the union, i.e. modularity results, trying to build on work in term 
rewriting systems such as [17, 13, 6]. 

We have discussed bridge rules as a communication means to integrate solvers 
with disjoint constraints utilizing completion. Finally, we have introduced a 
method to remove redundant rules from a CHR solver using our operational 
equivalence test and our confluence test to improve the efficiency of the CHR 
solver. An implementation of the approach on the basis of our confluence testing 
tool is certainly desirable to gain more practical experience. 

For future work, we are also interested in general notions of confluence and 
completion, since we have found that on larger examples, their current require- 
ments are unnecessarily strict. A more efficient method for detecting and remov- 
ing redundant rules should be found. 

Another open question is how the results that we obtained for CHR can be 
transferred to rewrite systems and other rule-based languages. Our work could 
serve as a starting point for developing a methodology for integration that is 
supported by semi-automatic tools. 

Last but not least we would like to thank the anonymous referees for often 
detailed and crucial comments that helped to improve and clarify our paper. 
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Abstract. Current-generation constraint programming languages are 
considered by many, especially in industry, to be too low-level, diffi- 
cult, and large. We argue that solver-independent, high-level relational 
constraint modelling leads to a simpler and smaller language, to more 
concise, intuitive, and analysable models, as well as to more efficient 
and effective model formulation, maintenance, reformulation, and veri- 
fication. All this can be achieved without sacrificing the possibility of 
efficient solving, so that even time-pressed or less competent modellers 
can be well assisted. Towards this, we propose the ESRA relational con- 
straint modelling language, showcase its elegance on some well-known 
problems, and outline a compilation philosophy for such languages. 



1 Introduction 

Current-generation constraint programming languages are considered by many, 
especially in industry, to be too low-level, difficult, and large. Consequently, 
their solvers are not in as widespread use as they ought to be, and constraint 
programming is still fairly unknown in many application domains, such as molec- 
ular biology. In order to unleash the proven powers of constraint technology and 
make it available to a wider range of problem modellers, a solver-independent, 
higher-level, simpler, and smaller modelling notation is needed. 

In our opinion, even recent commercial languages such as OPL [31] do not go 
far enough in that direction. Many common modelling patterns have not been 
captured in special constructs. They have to be painstakingly spelled out each 
time, at a high risk for errors, often using low-level devices such as reification. 

In recent years, modelling languages based on some logic with sets and re- 
lations have gained popularity in formal methods, witness the B [1] and z [29] 
specification languages, the alloy [16] object modelling language, and the Ob- 
ject Constraint Language (ocl) [35] of the Unified Modelling Language (uml) 
[27]. In semantic data modelling this had been long advocated; most notably via 
entity-relationship-attribute (ERA) diagrams. 

* A previous version of this paper appears pages 63-77 in the informally published pro- 
ceedings of the Second International Workshop Modelling and Reformulating CSPs, 
available at http : //www — users.cs.york.ac.uk/~frisch/Reformulation/03/ 
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Sets and set expressions started appearing as modelling devices in some con- 
straint languages. Set variables are often implemented by the set interval repre- 
sentation [13]. In the absence of such an explicit set concept, modellers usually 
painstakingly represent a set variable by its characteristic function, namely as a 
sequence of 0/1 integer variables, as long as the size of the domain of the set. 

Relations have not received much attention yet in constraint programming 
languages, except total functions, via arrays. Indeed, a total function / can be 
represented in many ways [15], say as a 1-dimensional array of variables over 
the range of /, indexed by its domain, or as a 2-dimensional array of Boolean 
variables, indexed by the domain and range of /, or as a 1-dimensional array 
of set variables over the domain of /, indexed by its range, or even with some 
redundancy. Other than retrieving the (unique) image under a total function of 
a domain element, there has been no support for relational expressions. 

Matrix modelling [8, 10, 31] has been advocated as one way of capturing com- 
mon modelling patterns. Alternatively, it has been argued [11, 15] that functions, 
and hence relations, should be supported by an abstract datatype (ADT). It is 
then the compiler that must (help the modeller) choose a suitable representa- 
tion, say in a contemporary constraint programming language, for each instance 
of the ADT, using empirically or theoretically gained modelling insights. 

We here demonstrate, as originally conjectured in [9], that a suitable first- 
order relational calculus is a good basis for a high-level, ADT-based, and solver- 
independent constraint modelling language. It gives rise to very natural and 
easy-to-maintain models of combinatorial problems. Even in the (temporary) 
absence of a corresponding high-level search language, this generality does not 
necessarily come at a loss in solving efficiency, as abstract relational models are 
devoid of representation details so that the results of analysis can be exploited. 

Our aims here are only to justify and present our new language, called ESRA, 
to illustrate its elegance and the flexibility of its models by some examples, and 
to argue that it can be compiled into efficient models in lower-level (constraint 
programming) languages. The syntax, denotational semantics, and type system 
of the proposed language are discussed in full detail in an online appendix [12] 
and a second prototype of the advocated compiler is under development. 

The rest of this paper is organised as follows. In Section 2, we present our 
relational language for modelling combinatorial problems and deploy it on three 
real-life problems before discussing its compilation. This allows us to list, in 
Section 3, the benefits of relational modelling. Finally, in Section 4, we conclude 
as well as discuss related and future work. 

2 Relational Constraint Modelling with ESRA 

In Section 2.1, we justify the design decisions behind our new ESRA constraint 
modelling language, targeted at constraint programmers. Then, in Section 2.2, 
we introduce its concepts, syntax, type system, and semantics. Next, in Sec- 
tion 2.3, we deploy esra on three real-life problems. Finally, in Section 2.4, we 
discuss the design of our prototype compilers for ESRA. 
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2.1 Design Decisions 

The key design decisions for our new relational constraint modelling language — 
called ESRA for Executable Symbolism for Relational Algebra — were as follows. 

We want to capture common modelling idioms in a new abstract datatype 
for relations, so as to design a high-level and simple language. The constructs of 
the language are orthogonal, so as to keep the language small. Computational 
completeness is not aimed at, as long as the language is useful for elegantly 
modelling a large number of combinatorial problems. 

We focus on finite, discrete domains. Relations are built from such domains 
and sets are viewed as unary relations. Theoretical difficulties are sidestepped 
by supporting only bounded quantification, but not negation nor sets of sets. 

The language has an ASCII syntax, mimicking mathematical and logical 
notation as closely as possible, as well as a RTEX-based syntax, especially used 
for pretty-printing models in that notation. 

2.2 Concepts, Syntax, Type System, and Semantics of ESRA 

For reasons of space, we only give an informal semantics. The interested reader 
is invited to consult [12] for a complete description of the language. Essentially, 
the semantics of the language is a conservative extension of existential second- 
order logic. Existential quantification of relations is used to assert that relations 
are to be found that satisfy sets of first-order constraints. This is in contrast 
with extensions of logic programming [6,25] where second-order relations can 
be specified recursively using Horn clauses, which needs a much more careful 
treatment of the fixed-point semantics. 

Code excerpts are here provided out of the semantic context of any particular 
problem statement, just to illustrate the syntax, but a suggested reading in plain 
English is always provided. In Section 2.3, we will actually start from plain 
English problem statements and show how they can be modelled in ESRA. Code 
excerpts are always given in the pretty-printed form, but we indicate the ASCII 
notation for every symbol where it necessarily differs. 

An ESRA model starts with a sequence of declarations of named domains 
(or types) as well as named constants and decision variables that are tied to 
domains. Then comes the objective, which is to find values for the decision vari- 
ables within their domains so that some constraints are satisfied and possibly 
some cost expression takes an optimal value. 



The Type System. A primitive domain is a finite, extensionally given set of 
new names or integers, comma-separated and enclosed as usual in curly braces. 
An integer domain can also be given intensionally as a finite integer interval, 
by separating its lower and upper bounds with ‘. . .’ (denoted in ASCII by ‘ . . ’), 
without using curly braces. When these bounds coincide, the corresponding sin- 
gleton domain n . . . n or {n} can be abbreviated to n. Context always determines 
whether an integer n designates itself or the singleton domain {n}. A domain 
can also be given intensionally using set comprehension notation. 
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The only predefined primitive domains are the sets N (denoted in ASCII by 
‘nat’) and Z (denoted in ASCII by ‘int’), which are ‘0. . .sup’ and ‘inf. . .sup’ 
respectively, where the predefined constant identifiers ‘inf and ‘sup’ stand for the 
smallest negative and largest positive representable integers respectively. User- 
defined primitive domains are declared after the ‘dom’ keyword and initialised 
at compile-time, using the ‘=’ symbol, or at run-time, via a datafile, otherwise 
interactively. 

Example 1. The statement 



dom Varieties, Bloeks 

declares two domains called Varieties and Bloeks that are to be initialised at run- 
time. As in OPL [31], this neatly separates the problem model from its instance 
data, so that the actual constraint satisfaction problem is obtained at run-time. 
Similarly, the statement 

dom Players = 1 . . .g * s, Weeks = 1 . . .w, Groups = 1 . . . g 

where g, s, w are integer-constant identifiers (assumed previously declared, in a 
way shown below), declares integer domains called Players, Weeks, and Groups 
that are initialised at compile-time. 

Finally, the declaration 

dom Even = {i | i : 0 . . . 100 | i % 2 = 0} 

initialises the domain Even of all even natural numbers up to 100. 

The usual binary infix x constructor (denoted in ASCII by ‘#’) allows the 
construction of Cartesian products. 

The only eonstructed domains are relational domains. In order to simulta- 
neously capture frequently occurring multiplicity constraints on relations, we 
offer a parameterised binary infix x domain constructor. The relational domain 
A -^ 1 x ^2 where A and B are (possibly Cartesian products of) primitive do- 
mains, designates a set of binary relations in Ax B. The optional M\ and M 2 , 
called multiplicities, must be integer sets and have the following semantics: for 
every element a of A, the number of elements of B related to a must be in Mi, 
while for every element b of B, the number of elements of A related to b must 
be in M 2 An omitted multiplicity stands for N. 

Example 2. The constructed domain 

Varieties '’x^ Bloeks 

designates the set of all relations in Varieties x Blocks where every variety occurs 
in exactly r blocks and every block contains exactly k varieties. These are two 
occurrences where an integer abbreviates the singleton domain containing it. 

^ Note that our syntax is the opposite of the UML one, say, where the multiplicities are 
written in the other order, with the same semantics. That convention can however 
not be usefully upgraded to Cartesian products of arity higher than 2. 
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In the absence of such facilities for relations and their multiplicities, a re- 
lational domain would have to be modelled using arrays, say. This may be a 
premature commitment to a concrete data structure, as the modeller may not 
know yet, especially prior to experimentation, which particular (array-based) 
representation of a relational decision variable will lead to the most efficient 
solving. The problem constraints, including the multiplicities, would have to be 
formulated in the constraints part of the model, based on the chosen represen- 
tation. If the experiments revealed that another representation should be tried, 
then the modeller would have to first painstakingly reformulate the declaration 
of the decision variable as well as all its constraints. Our ADT view of relations 
overcomes this flaw: it is now the compiler that must (help the modeller) choose 
a suitable representation for each instance of the ADT by using empirically or 
theoretically gained insights. Also, multiplicities need not become counting con- 
straints, but are succinctly and conveniently captured in the declaration. 

We view sets as unary relations: A M, where A is a domain and M an integer 
set, constructs the domain of all subsets of A whose cardinality is in M. The 
multiplicity M is mandatory here; otherwise there would be ambiguity whether 
a value of the domain A is an element or an arbitrarily sized subset of A. 

For total and partial functions, the left-hand multiplicity Mi is 1 ... 1 and 
0 . . . 1 respectively. In order to dispense with these left-hand multiplicities for 
total and partial functions, we offer the usual — >■ and 7 ^ (denoted in ASCII 
by and ‘+>’) domain constructors respectively, as shorthands. They may still 
have right-hand multiplicities though. 

For injections, surjections, and bijections, the right-hand multiplicity M 2 is 
0 . . . 1, 1 . . . sup, and 1 ... 1 respectively. Rather than elevating these particular 
cases of functions to first-class concepts with an invented specific syntax in ESRA, 
we prefer keeping our language lean and close to mathematical notation. 

Example 3. The constructed domain 

{Players x Weeks) — Groups 

designates the set of all total functions from Players x Weeks into Groups such 
that every group is related to exactly sw (player, week) pairs. 

We provide no support (yet) for bags and sequences, as relations provide 
enough challenges for the time being. Note that a bag can be modelled as a total 
function from its domain into N, giving the repetition count of each element. 
Similarly, a sequence of length n can be modelled as a total function from 1 . . . n 
into its domain, telling which element is at each position. This does not mean 
that the representation of bags and sequences is fixed (to the one of total func- 
tions), because, as we shall see in Section 2.4, the various relations (and thus 
total functions) of a model need not have the same representation. 



Modelling the Instance Data and Decision Variables. All identifier dec- 
larations are strongly typed and denote variables that are implicitly universally 
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quantified over the entire model, with the constants expected to be ground before 
search begins while the decision variables can still be unbound at that moment. 

Like the user-defined primitive domains, constants help describe the instance 
data of a problem. A constant identifier is declared after the ‘cst’ keyword and 
is tied to its domain by meaning set membership. Constants are initialised 
at compile-time, using the ‘=’ symbol, or at run-time, via a datafile, otherwise 
interactively. Again, run-time initialisation provides a neat separation of problem 
models and problem instances. 

Example 4- The statement 

cst r,k,\:N 

declares three natural number constants that are to be initialised at run-time. 

As already seen in Examples 2 and 3, the availability of total functions makes 
arrays unnecessary. The statement 

cst CrewSize : Guests — > N, SpareCap : Hosts — > N 

declares two natural- number functions, to be provided at run-time. 

A decision-variable identifier is declared after the ‘var’ keyword and is tied 
to its domain by 

Example 5. The statement 

var BIBD : Varieties ’’x* Blocks 

declares a relation called BIBD of the domain of Example 2. 



Modelling the Cost Expression and the Constraints. Expressions and 
first-order logic formulas are constructed in the usual way. 

For numeric expressions, the arguments are either integers or identifiers of the 
domain N or Z, including the predefined constants ‘inf and ‘sup’. Usual unary 
(— , ‘abs’ for absolute value, and ‘card’ for the cardinality of a set expression), 
binary infix (-f, — , *, / for integer quotient, and % for integer remainder), and 
aggregate (^, denoted in ASCII by ‘sum’) arithmetic operators are available. A 
sum is indexed by local variables ranging over finite sets, which may be filtered 
on-the-fly by a condition given after the ‘|’ symbol (read ‘such that’). 

Sets obey the same rules as domains. So, for set expressions, the arguments 
are either set identifiers or (intensionally or extensionally) given sets, including 
the predefined sets N and Z. Only the (unparameterised) binary infix domain 
constructor x and its specialisations — >■ and are available as operators. 

Finally function expressions are built by applying a function identifier to an 
argument tuple. We have found no use yet for any other operators on functions 
(but see the discussion of future work in Section 4). 

Example 6. The numeric expression 



g:Guests \ 



E 



CrewSize(g) 



Schedule{g,p)—h 
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denotes the sum of the crew sizes of all the guest boats that are scheduled to 
visit host h at period p, assuming this expression is within the scope of the local 
variables h and p. The nested function expression CrewSize(g) stands for the 
size of the crew of guest g, which is a natural number according to Example 4. 

Atoms are built from numeric expressions with the usual comparison predi- 
cates, such as the binary infix =, and < (denoted in ASCII by ‘=’, ‘!=’, and 
‘=<’ respectively). Atoms also include the predefined ‘true’ and ‘false’, as well as 
references to the elements of a relation. We have found no use yet for any other 
predicates. Note that ‘G’ is unnecessary as x G S' is equivalent to S{x). 

Example 7. The atom BIBD{vi, i) stands for the truth value of variety vi being 
related to block i in the BIBD relation of Example 5. 

Formulas are built from atoms. The usual binary infix connectives (A, V, =>, 
<^=, and denoted in ASCII by ‘/\’, ‘\/’, ‘=>’, ‘<=’, and ‘<=>’ respectively) and 
quantifiers (V and 3, denoted in ASCII by ‘f orall’ and ‘exists’ respectively) are 
available. A quantified formula is indexed by local variables ranging over finite 
sets, which may be filtered on-the-fly by a condition given after the ‘|’ symbol 
(read ‘such that’). As we provide a rich (enough) set of predicates, we are only 
interested in models that can be formulated positively, and thus dispense with 
the negation connective. The usual typing and precedence rules for operators 
and connectives apply. All binary operators associate to the left. 

Example 8. The formula 

V(p : Periods, h : Hosts) CrewSize(g) < SpareCap(h) 

\g:Guests \ Schedule{g,p) — h j 

constrains the spare capacity of any host boat h not to be exceeded at any period 
p by the sum of the crew sizes of all the guest boats that are scheduled to visit 
host h at period p. 

A generalisation of the 3 quantifier turns out to be very useful. We define 
co\mt{Multiplicity){x : Set \ Condition) 

to hold if and only if the cardinality of the set comprehension {x : Set\Condition} 
is in the integer set Multiplicity. So 

3(x : Set \ Condition) 

is actually syntactic sugar for 

count(l . . .sup)(cc : Set \ Condition) 

Example 9. The formula 



V(ui < V 2 ■ Varieties) count(A)(j : Blocks \ BIBD{v\,j) A BIBD{v 2 ,j)) 
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says that each ordered pair of varieties v\ and i >2 occurs together in exactly A 
blocks, via the BIBD relation. Regarding the excerpt ^v\ < V 2 ■ Varieties\ note 
that multiple local variables can be quantified at the same time, and that a 
filtering condition on them may then be pushed across the ‘|’ symbol. 

Example 10. Assuming that the function Schedule is of the domain of Example 3 
and thus returns a group, the formula 

V(pi < p 2 ■ Players) count(0 . . . l)(u : Weeks \ Schedule{pi,v) = Schedule{p 2 ,v)) 

says that there is at most one week where any ordered pair of players pi and p 2 
is scheduled to play in the same group. 

A cost expression is a numeric expression that has to be optimised. The con- 
straints on the decision variables of a model are a conjunction of formulas, using 
A as the connective. The objective of a model is either to solve its constraints: 

solve Constraints 

or to minimise the value of its cost expression subject to its constraints: 

minimise CostExpression such that Constraints 

or similarly for maximising. A model consists of a sequence of domain, constant, 
and decision-variable declarations followed by an objective, without separators. 

Example 11. Putting together code fragments from Examples 1, 4, 5, and 9, we 
obtain the model of Figure 2 two pages ahead, discussed in Section 2.3. 

The grammar of ESRA is described in Figure 1. For brevity and ease of read- 
ing, we have omitted most syntactic-sugar options as well as the rules for iden- 
tifiers, names, and numbers. The notation (nt)* stands for a sequence of zero 
or more occurrences of the non-terminal {nt), separated by symbol s. Similarly, 
(nt)* stands for one or more occurrences of {nt), separated by s. The typing 
rules ensure that the equality predicates = and ^ are only applied to expres- 
sions of the same type, that the other comparison predicates, such as <, are only 
applied to numeric expressions, and so on. 

2.3 Examples 

We now showcase the elegance and flexibility of our language on three real- 
life problems, namely Balanced Incomplete Block Designs, the Social Golfers 
problem, and the Progressive Party problem. 



Balanced Incomplete Block Designs. Let V be any set of v elements, called 
varieties. A balanced incomplete block design (BIBD) is a bag of b subsets of 
V, called blocks, each of size k (constraint Gi), such that each pair of distinct 
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(Model) ::= (Dec/)"*" (Objective) 

(Decl) ::= (DomDecl) \ (CstDecl) \ (VarDecl) 

(DomDecl) ::= dom (Id) [ = (Set) ] 

(CstDecl) ::= cst (Id) [ = (Tuple) \ (Set) ] : (SetExpr) 

(VarDecl) var (Id) : (SetExpr) 

(Objective) ::= solve (Formula) 

I ( minimise | maximise ) (NumExpr) such that (Formula) 

(Expr) ::= (Id) \ (Name) \ (Tuple) \ (NumExpr) \ (SetExpr) \ (FuncAppl) \ ( (Expr) ) 

(NumExpr) ::= (Id) \ (Int) \ (Nat) \ inf | sup | (FuncAppl) 

I (NumExpr) ( + | ~ | * | / | % ) (NumExpr) 

I ( - I abs ) (NumExpr) 

I card (SetExpr) 

I sum ( (QuantExpr) ) ( (NumExpr) ) 

(SetExpr) ::= (Set) \ (SetExpr) l(Set)'\ 

I (SetExpr) ( [[{5'e£}]#[(5e£}]] | # ) (SetExpr) 

I (SetExpr) ( [->[{5'et}]] | -> | [+>[{5'et}]] | +> ) (SetExpr) 

(Set) ::= (Id) \ int | nat 

I { (Tuple)* } I { (ComprExpr) } 

I (NumExpr) . .(NumExpr) \ (NumExpr) 

(ComprExpr) ::= (Expr) \ ( (IdTuple)^^ in (SetExpr) [ I (Formula) ] 

(FuncAppl) ::= (Id) (Tuple) 

(Tuple) ::= ((Expr)’^) \ (Expr) 

(Formula) ::= true | false | (RelAppl) 

I (Formula) ( A | \/ | => | <= | <=> ) (Formula) 

I (NumExpr) ( < | =< | = | >= | > | ! = ) (NumExpr) 

I forall ( (QuantExpr) ) ( (Formula) ) 

I count ( (Set) ) ( (QuantExpr) ) 

(RelAppl) ::= (Id) (Tuple) 

(QuantExpr) ::= ( ( (RelQvars) \ (IdTuple)^^ ) in (SetExpr) [ | (Formula) ] 
(RelQvars) ::= (Expr) ( < | =< | = | >= | > | ! = ) (Expr) 

(MTuple) ::= (Id) \ ( (Id ) ) 



Fig. 1. The grammar of ESRA 



varieties occurs together in exactly A blocks {C 2 ), with 2 < k < v. An implied 
constraint is that each variety occurs in the same number of blocks (Cs), namely 
r = \{v — l)/{k — 1). A BIBD is parameterised by a 5-tuple {v,b,r,k,X) of 
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dom Varieties, Bloeks 
cst r, fc, A : N 

var BIBD : Varieties Blocks 
solve 

V(ui < V 2 : Varieties) count(A)(ji : Blocks \ BIBD{vi,j) A BIBD{v 2 , j)) 
Fig. 2. A pretty-printed ESRA model for BIBDs 

dom Varieties, Blocks 

cst r, k, lambda : nat 

var BIBD : Varieties [r#k] Blocks 

solve 

forall (vl < v2 : Varieties) 

count (lambda) (j : Blocks I BIBD(vl,j) /\ BIBD(v2,j)) 

Fig. 3. An ESRA model for BIBDs 



parameters. Originally intended for the design of statistical experiments, BIBDs 
also have applications in cryptography and other domains. See Problem 28 at 
http : //www . csplib . org for more information. 

The instance data can be declared as the two domains Varieties and Blocks , of 
implicit sizes v and b respectively, as well as the three natural-number constants 
r, k, and A, as in Examples 1 and 4. A unique relational decision variable, 
BIBD, can then be declared as in Example 5, thereby immediately taking care 
of the constraints Ci and C 3 . The remaining constraint C 2 can be modelled as 
in Example 9. Figure 2 shows the resulting pretty-printed ESRA model, while 
Figure 3 shows it in ASCII notation. 

For comparison, an OPL [31] model is shown in Figure 4, where ‘= . . . ’ means 
that the value is to be found in a corresponding datafile. The decision variable 
BIBD is a 2-dimensional array of integers 0 or 1, indexed by the varieties and 
blocks, such that BIBD[i,j] = 1 iff variety i is contained in block j. Further- 
more, the constraints Ci and C 3 , which we could capture by multiplicities in the 
ESRA model, need here to be stated in more length. Finally, the constraint C 2 
is stated using a higher-order constraint^: for each ordered pair of varieties vl 
and v2, the number of times they appear in the same block, that is the number 
of blocks j where BIBD(vl,j) = 1 = BIBD(v2,j) holds, must equal lemibda. 

In an OPL model, one needs to decide what concrete datatypes to use for 
representing the abstract decision variables of the original problem statement. 
In this case, we chose a 2-dimensional 0/1 array BIBD, indexed by Varieties 
and Blocks. We could just as well have chosen a different representation, say (if 
OPL had set variables) a 1-dimensional array BIBD, indexed by Blocks, of subsets 
of Varieties. Such a choice affects the formulation of every constraint and the 
cost expression, but is premature as even expert intuition is weak in predicting 
which representation choice leads to the best solving efficiency. Consequently, the 
modeller has to frequently reformulate the constraints and the cost expression 

^ A higher-order constraint refers to the truth value of another constraint. In OPL, the 
latter is nested in parentheses, truth is represented by 1, and falsity by 0. 
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enum Varieties = . . . , Blocks = . . . ; 

int r = . . . ; int k = . . . ; int lambda = . . . ; 

range Boolean 0..1; 

var Boolean BIBD [Varieties, Blocks] ; 

solve { 

foralKj in Blocks) sum(i in Varieties) BIBD[i,j] = k; 
foralKi in Varieties) sum(j in Blocks) BIBD[i,j] = r; 
forall (ordered vl,v2 in Varieties) 

sum(j in Blocks) (BIBD[vl,j] = 1 = BIBD[v2,j]) = lambda; 

. . . symmetry-breaking code . . . 

>; 

Fig. 4. An OPL model for BIBDs 

while experimenting with different representations. No such choices have to be 
made in an ESRA model, making ESRA a more convenient modelling language. 

As a consequence to such representation choices, one often introduces an as- 
tronomical amount of symmetries into an OPL model that are not present in the 
original problem statement [10]. For example, given a solution, any two rows 
or columns in the array BIBD can be swapped, giving a different, but symmet- 
rically equivalent, solution. Such symmetries need to be addressed in order to 
achieve efficient solving. Hence, symmetry-breaking code [10,32] would have to 
be inserted, as indicated in Figure 4. Since such choices are postponed to the 
compilation phase in ESRA (see Section 2.4), any symmetries consciously intro- 
duced can be handled (automatically) in that process. 

The Social Golfers Problem. In a golf club, there are n players, each of 
whom plays golf once a week (constraint C\) and always in g groups of size s 
(C 2 ), hence n = gs. The objective is to determine whether there is a schedule of 
w weeks of play for these golfers, such that there is at most one week where any 
two distinct players are scheduled to play in the same group (G 3 ). An implied 
constraint is that every group occurs exactly sw times across the schedule (C 4 ). 
See Problem 10 at http://www.csplib.org for more information. 

The instance data can be declared as the three natural-number constants 
g, s, and w, via ‘cst g,s,w : N’, as well as the three domains Players, Weeks, 
and Blocks, as in Example 1. A unique decision variable. Schedule, can then be 
declared using the functional domain in Example 3, thereby immediately taking 
care of the constraints Ci (because of the totality of the function) and C 4 . The 
constraint C 3 can be modelled as in Example 10. The constraint C 2 can be stated 
using the count quantifier, as seen in the pretty-printed ESRA model of Figure 5. 

Note the different style of modelling sets of unnamed objects, via the separa- 
tion of models from the instance data, compared to Figure 2. There we introduce 
two sets without initialising them at the model level, while here we introduce 
three uninitialised constants that are then used to arbitrarily initialise three 
domains of desired cardinalities. Both models can be reformulated in the other 
style. The benefit of such sets of unnamed objects is that their elements are indis- 
tinguishable, so that lower-level representations of relational decision variables 
whose domains involve such sets are known to introduce symmetries. 
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cst g, s, w : N 

dom Players = 1 . . . g * s, Weeks = 1 . . . w, Groups = 1 . . . g 

var Schedule : {Players x Weeks) — Groups 

solve 

V(pi < P 2 : Players) count(0. . . l)(u : Weeks \ Schedule{pi,v) = Schedule{p 2 ,v)) 
A V(/i : Groups, V : Weeks) count(s)(p : Players \ Sehedule{p,v) = h) 

Fig. 5. A pretty-printed ESRA model for the Social Golfers problem 



dom Guests, Hosts, Periods 

cst SpareGap : Hosts — > N, GrewSize : Guests — > N 

var Schedule : {Guests x Periods) — > Hosts 

solve 

V(p : Periods, h : Hosts) ( GrewSize{g) I < SpareGap{h) 

\g:Guests \ Schedule{g,p) = h j 

A V(g : Guests, h : Hosts) count(0 . . . l){p : Periods \ Schedule{g,p) = h) 

A V(gi < g 2 : Guests) count(0. . . l){p : Periods \ Schedule{gi,p) = Schedule{g 2 ,p)) 

Fig. 6. A pretty-printed ESRA model for the Progressive Party problem 



The Progressive Party Problem. The problem is to timetable a party at 
a yacht club. Certain boats are designated as hosts, while the crews of the 
remaining boats are designated as guests. The crew of a host boat remains 
on board throughout the party to act as hosts, while the crew of a guest boat 
together visits host boats over a number of periods. The spare capacity of any 
host boat is not to be exceeded at any period by the sum of the crew sizes of 
all the guest boats that are scheduled to visit it then (constraint Ci). Any guest 
crew can visit any host boat in at most one period (C*2). Any two distinct guest 
crews can visit the same host boat in at most one period (Ca). See Problem 13 
at http : / /www . csplib . org for more information. 

The instance data can be declared as the three domains Guests, Hosts, and 
Periods, via ‘dom Guests, Hosts, Periods', as well as the two functional constants 
SpareGap and GrewSize, as in Example 4. A unique functional decision variable. 
Schedule, can then be declared via ‘var Schedule : {Guests x Periods) — > Hosts'. 
The constraint Ci can now be modelled as in Example 8. The constraints C 2 
and C3 can be stated using the count quantifier, as seen in the pretty-printed 
ESRA model of Figure 6. 



2.4 Compiling Relational Models 

A compiler for ESRA is currently under development. It is being written in OCAML 
(http://www.ocaml.org) and compiles ESRA models into SICStus Prolog [5] 
finite-domain constraint programs. Our choice of target language is motivated 
by its excellent collection of global constraints and by our collaboration with its 
developers on designing new global constraints. 
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We already have an ESRA-to-OPL compiler [36,15], written in Java, for a 
restriction of ESRA to functions, now called Functional-ESRA. That project gave 
us much of the expertise needed for developing the current compiler. 

The solver-independent ESRA language is so high-level that it is very small 
compared to such target languages, especially in the number of necessary prim- 
itive constraints. The full panoply of features of such target languages can, 
and must, be deployed during compilation. In particular, the implementation 
of decision- variable indices into matrices is well-understood. 

In order to bootstrap our new compiler quickly, we decided to represent 
initially every relational decision variable by a matrix of 0/1 variables, indexed by 
its participating sets. This first version of the new compiler is thus deterministic. 

The plan is then to add alternatives to this unique representation rule, de- 
pending on the multiplicities and other constraints on the relation, achieving a 
non- deterministic compiler, such as our existing Functional-ESRA-to-OPL com- 
piler [36,15]. The modeller is then invited to experiment with her (real-life) 
instance data and the resulting compiled programs, so as to determine which 
one is the ‘best’. If the compiler is provided with those instance data, then it 
can be extended to automate such experiments and generate rankings. 

Eventually, more intelligence will be built into the compiler via heuristics 
(such as those of [15]) for the compiler to rank the resulting compiled programs 
by decreasing likelihood of efficiency, without any recourse to experiments. In- 
deed, depending on the multiplicities and other constraints on a relation, certain 
representations thereof can be shown to be better than others, under certain as- 
sumptions on the targeted solver, and this either theoretically (see for instance 
[33] for bijections and [15] for injections) or empirically (see for instance [28] for 
bijections). We envisage a hybrid interactive/heuristic compiler. 

Our ultimate aim is of course to design an actual solver for relational con- 
straints, without going through compilation. 



3 Benefits of Relational Modelling 

In our experience, and as demonstrated in Section 2.3, a relational constraint 
modelling language leads to more concise and intuitive models, as well as to more 
efficient and effective model formulation and verification. Due to ESRA being 
smaller than conventional constraint programming languages, we believe it is 
easier to learn and master, making it a good candidate for a teaching medium. 
All this could entail a better dissemination of constraint technology. 

Relational languages seem a good trade-off between generality and specificity, 
enabling efficient solving despite more generality. Relations are a single, pow- 
erful concept for elegantly modelling many aspects of combinatorial problems. 
Also, there are not too many different, and even standard, ways of representing 
relations and relational expressions. Known and future modelling insights, such 
as those in [15, 28, 33], can be built into the compilers, so that even time-pressed 
or less competent modellers can benefit from them. Modelling is unencumbered 
by early if not uninformed commitments to representation choices. Low-level 




Introducing ESRA, a Relational Language 



227 



modelling devices such as reification and higher-order constraints can be en- 
capsulated as implementation devices. The number of decision variables being 
reduced, there is even hope that directly solving the constraints at the high re- 
lational level can be faster than solving their compiled lower-level counterparts. 
All this illustrates that more generality need not mean poorer performance. 

Relational models are more amenable to maintenance when the combina- 
torial problem changes, because most of the tedium is taken care of by the 
compiler. Model maintenance at the relational level reduces to adapting to the 
new problem, with all representation (and solving) issues left to the compiler. 
Very little work is involved here when a multiplicity change entails a preferable 
representation change for a relation. Maintenance can even be necessary when 
the statistical distribution of the problem instances that are to be solved changes 
[22]. If information on the new distribution is given to the envisaged compiler, 
a simple recompilation will take care of the maintenance. 

Relational models are at a more suitable level for possibly automated model 
reformulation, such as via the inference and selection of suitable implied con- 
straints, with again the compiler assisting in the more mundane aspects. In the 
BIRD and Social Golfers examples, we have observed that multiplicities provide 
a nice framework for discovering and stating some implied constraints. Indeed, 
the language makes the modeller think about making these multiplicities explicit , 
even if they were not in the original problem formulation. 

Relational models are more amenable to constraint analysis. Detected prop- 
erties as well as properties consciously introduced during compilation into lower- 
level programs, such as symmetry or bijectiveness, can then be taken into account 
during compilation [10], especially using tractability results [32]. 

There would be further benefits to an abstract modelling language if it were 
adopted as a standard front-end language for solvers. Models and instance data 
would then be solver-independent and could be shared between solvers, whatever 
their technology. Indeed, the targeted solvers need not even use constraint tech- 
nology, but could just as well use answer-set programming, linear programming, 
local search, or propositional satisfiability technology, or any hybrid thereof. 
This would facilitate fair and homogeneous comparisons, say via new standard 
benchmarks, as well as foster competition in fine-tuning the compilers. 



4 Conclusion 

We have argued that solver-independent, abstract constraint modelling leads to 
a simpler and smaller language; to more concise, intuitive, and analysable mod- 
els; as well as to more efficient and effective model formulation, maintenance, 
reformulation, and verification. All this can be achieved without sacrificing the 
possibility of efficient solving, so that even time-pressed or less competent mod- 
ellers can be well assisted. Towards this, we have proposed the ESRA relational 
modelling language, showcased its elegance on some well-known problems, and 
outlined a compilation philosophy for such languages. To conclude, let us look 
at related work (Section 4.1) and future work (Section 4.2). 
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4.1 Related Work 

We have here generalised and re-engineered our own work [11,36, 15] on a pre- 
decessor of ESRA, now called Functional-ESRA, that only supports functional 
decision variables, by pursuing the aim of relational modelling outlined in [9]. 
Elsewhere, such ideas have recently inspired a related project [3], incorporating 
partition decision variables. Constraints for bag decision variables [2,7,34] and 
sequence decision variables [2, 26] have also been proposed. 

This research owes a lot to previous work on relational modelling in formal 
methods and on ERA-style semantic data modelling, especially to the alloy 
object modelling language [16], which itself gained much from the z specification 
notation [29] (and learned from uml/ocl how not to do it). Contrary to ERA 
modelling, we do not distinguish between attributes and relations. 

In constraint programming, the commercial OPL [31] stands out as a medium- 
level modelling language and actually gave the impetus to design ESRA: see the 
BIRD example in Section 2.3 and consult [9] for a further comparison of elegant 
ESRA models with more awkward (published) OPL counterparts that do not 
provide all the benefits of Section 3. Other higher-level constraint modelling 
languages than ESRA have been proposed, such as ALICE [18], CLP{Fun{D)) 
[14], CLPS [2], CON JUNTO [13], EACL [30], {log} [7], NCL [37], and the language of 
[24] . Our ESRA shares with them the quest for a practical declarative modelling 
language based on a strongly-typed fuller first-order logic than Horn clauses, with 
sequence, set, bag, functional, or even relational decision variables, while often 
dispensing with recursion, negation, and unbounded quantification. However, 
ESRA goes way beyond them, by advocating an ADT view (of relations), so that 
representations need not be fixed in advance, by providing an elegant notation 
for multiplicity constraints, and by promising intelligent compilation. 

In the field of knowledge representation, answer-set programming (ASP) has 
recently been advocated [21] as a practical constraint solving paradigm, espe- 
cially for dynamic domains such as planning. A set of (disjunctive) function-free 
clauses, where classical negation and negation as failure are allowed, is inter- 
preted as a constraint, stating when an atom is in a solution, called an answer set 
or a stable model. This non-monotonic approach differs from constraint (logic) 
programming, where statements are used to add atomic constraints on decision 
variables to a constraint store, whereupon propagation and search are used to 
construct solutions. Implementation methods for computing the answer sets of 
ground programs have advanced significantly over recent years, possibly using 
propositional satisfiability (SAT) solvers. Also, effective grounding procedures 
have been devised for some classes of such programs with (schematic) variables. 
Sample ASP systems are dlv [19] and smodels [23]. Closely related are Con- 
straintLingo [8] and np-SPEC [4]. The languages of these systems include useful 
features, such as cardinality and weight constraints, aggregate functions, and 
soft constraints. They have strictly more expressive power than propositional 
logic and traditional constraint (logic) programming/modelling languages, in- 
cluding ESRA. Again, our objective only is a language that is useful for elegantly 
modelling a large number of combinatorial problems. The cardinality constraint 
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dom Cities 

cst Distance : {Cities x Cities) — > N 
var Next : Cities — Cities 
minimise Distance{c, Next{c)) 

c: Cities 

such that V(ci&C 2 : Cities) Next*{c\) = C 2 

Fig. 7 . A pretty-printed ESRA model for the Travelling Salesperson problem 



of SMODELS is a restriction of the ESRA ‘count’ quantifier to interval multiplici- 
ties, as opposed to set multiplicities. Speed comparisons with SAT solvers were 
encouraging, but no comparison has been done yet with constraint solvers. 



4.2 Future Work 

Most of our future work has already been listed in Sections 2.4 and 3 about 
the compiler design and long-term benefits of relational modelling, such as the 
generation of implied constraints and the breaking of symmetries. 

We have argued that our ESRA language is very small. This is mostly because 
we have not yet identified the need for any other operators or predicates. An 
exception to this is the need for transitive closure relation constructors. We 
aim at modelling the well-known Travelling Salesperson (TSP) problem as in 
Figure 7, where the transitive closure of the bijection Next on Cities is denoted 
by Next* . This general mechanism avoids the introduction of an ad hoc ‘circuit’ 
constraint as in ALICE [18]. 

As we do not aim at a complete constraint modelling language, we can be 
very conservative in what missing features shall be added to ESRA when they 
are identified. Also, for manpower reasons, we do not yet propose other ADTs, 
say for bags or sequences, although this was originally part of our original vision 
(see Section 3.3 of [11]). 

Our request for explicit model-level distinction between constants and deci- 
sion variables may be eventually lifted, as the default is run-time initialisation: 
we could treat as constants any universally quantified variable that was actually 
initialised and treat all the others as decision variables. This requires a convinc- 
ing example, though, as well as just-in-time compilation. 

In [20], a type system is derived for binary relations that can be used as an 
input to specialised filtering algorithms. This kind of analysis can be integrated 
into the relational solver we have in mind. 

Also, a graphical language could be developed for the data modelling, includ- 
ing the multiplicity constraints on relations, so that only the cost expression and 
the constraints would need to be textually expressed. 

Finally, a search language, such as SALSA [17] or the one of OPL [31], but at 
the level of relational modelling, should be adjoined to the constraint modelling 
language proposed here, so that more expert modellers can express their own 
search heuristics. 
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